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Предисловие 


Приходилось ли вам когда-нибудь 


тратить уйму времени на программирование неправильного алгоритма? 
пользоваться структурой данных, сложность которой превосходила всякое 
понимание? 

пропускать ошибку, лежащую на поверхности, даже при самом тщательном 
тестировании программы? 

возиться целый день с исправлением ошибки, на которую следовало бы потра- 
тить пять минут? 

дорабатывать программу так, чтобы она работала втрое быстрее и при этом 
потребляла меньше памяти? 

в муках переносить программу с рабочей станции на персональный компьютер 
или наоборот? 

вносить “косметические” изменения в программы, написанные кем-то другим? 
переписывать программу начисто, потому что она была совершенно неудобо- 
читаема? 


Скорее всего, вам это не понравилось. Что ж, подобное случается с программи- 
стами постоянно. Решение этих проблем часто оказывается более трудоемким, чем 
следовало бы, потому что такие темы, как тестирование, отладка, переносимость, 
быстродействие, стиль, проектирование программ — т.е. практика программирова- 
ния, — вовсе не являются центральными в вузовских курсах программирования и 
вычислительной техники. Большинству программистов приходится осваивать все 
это хаотически, по мере накопления опыта, а некоторым из них вообще не судьба 
этому научиться. 

В мире объемных и изощренных интерфейсов, постоянно изменяющихся языков, 
сред и утилит разработки, под давлением необходимости осваивать все новые и но- 
вые знания нетрудно потерять основной ориентир — такие базовые принципы, как 
простоту, ясность, общность, которые образуют фундамент для разработки высоко- 
качественных программ. Увы, людям свойственно переоценивать роль стандартов и 
автоматизированных сред программирования, которые механизируют значительную 
часть разработки программ, так что компьютер в известной степени становится сам 
себе программистом. 

Подход, принятый нами в этой книге, основан именно на глубоких и взаимосвя- 
занных принципах, применимых в программировании любого уровня. Эти принци- 
пы следующие. Простота означает, что программа должна быть короткой и легкой 
для доработки; ясность состоит в том, что ни у программиста при чтении програм- 
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мы, ни у компьютера при ее выполнении не должно возникать сомнений и ощуще- 
ния двусмысленности; общность заключается в способности программы правильно 
реагировать на широкий диапазон ситуаций и легко адаптироваться к новой обста- 
новке; наконец, автоматизация (ради которой, собственно, и пишутся программы) 
призвана освободить человека от трудоемких и однообразных операций. Рассматри- 
вая искусство программирования на самых разных языках и в широкой предметной 
области — от алгоритмов и структур данных до архитектуры, отладки, тестирования 
и повышения быстродействия, — можно проиллюстрировать универсальные инже- 
нерные концепции, независимые от конкретного языка, операционной системы или 
среды программирования. 

Эта книга возникла как результат многолетнего опыта в области разработки и 
доработки самого разного программного обеспечения, преподавания курсов про- 
граммирования и вычислительной техники, а также работы с огромным количеством 
программистов. Нам хочется поделиться усвоенными практическими уроками, 
предложить целый ряд методов и техник, которые бы помогли программистам всех 
уровней повысить свою квалификацию и производительность труда. 

Мы пишем для нескольких категорий читателей. Если вы — студент, уже прошли 
несколько предметов из курса программирования и вычислительной техники и 
хотите лучше научиться программировать практические задачи, то в этой книге вы 
найдете более подробное изложение некоторых тем, недостаточно освещенных в 
учебной программе. Если вы пишете программы по роду своей деятельности, но ско- 
рее в качестве вспомогательных средств, а не основных продуктов производства, то 
приведенные в книге сведения помогут вам программировать на этом уровне более 
эффективно. Предлагаемый материал окажется полезным также в том случае, если 
вы — профессиональный программист, но в свое время не получили достаточных 
знаний по тем или иным вопросам из программы вуза (или же хотели бы освежить 
их в памяти). Наконец, немало интересного найдет здесь руководитель коллектива 
по разработке программного обеспечения, желающий научить своих подчиненных 
работать лучше. 

Надеемся, что изучение материала этой книги пойдет на пользу вашим програм- 
мам. Единственное требование к подготовке читателя — это некоторый опыт програм- 
мирования, лучше всего на языках С, С++ или Јауа. Конечно, чем больше опыта, тем 
лучше; никто и ничто не может сделать специалиста из новичка за две-три недели. 
Программисты для систем Ошх и Глпих найдут в наших примерах больше знакомых 
мест и характерных черт, чем те, кто работал только в средах \/т4о\з и Масіпѓоѕћ. 
Тем не менее узнать что-то новое из книги и тем самым облегчить свою работу сможет 
практически каждый читатель, в какой бы среде он ни программировал. 


Материал книги подразделяется на девять глав, каждая из которых посвящена 
одному большому и важному аспекту практического программирования. 

В главе 1 рассматривается стиль программирования. Хороший стиль настолько 
важен для успешной работы программиста, что мы решили поставить его на первое 
место в книге. Хорошо написанные программы работают лучше, чем написанные 
плохо, — в них меньше ошибок, и их легче исправлять или отлаживать. Поэтому о 
хорошем стиле нужно помнить с самого начала. В этой же главе сделано введение в 
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такую важную тему, как использование устойчивых конструкций, характерных для 
того или иного языка. 

Глава 2 посвящена алгоритмам и структурам данных, которые традиционно 
составляют основу вузовских учебных планов по программированию и вычисли- 
тельной технике. Поскольку большинство читателей наверняка знакомы с этой 
тематикой, в нашем изложении мы дадим лишь краткий обзор основных алгоритмов 
и структур данных, используемых практически во всех программах. Более сложные 
конструкции обычно строятся их этих элементарных “кирпичиков”, поэтому их зна- 
ние имеет основополагающий характер. 

В главе 3 рассматриваются архитектура и реализация небольшой программы, ко- 
торая иллюстрирует вопросы алгоритмизации и структуризации данных в реали- 
стической манере, приближенной к практической работе. Эта программа написана 
на пяти языках. Сравнение различных ее версий позволяет оценить, как одни и те же 
структуры данных реализованы в каждом из языков и как отличаются выразитель- 
ность и эффективность аналогичных конструкций в различных средах программи- 
рования. 

Способы взаимодействия (интерфейсы) пользователя, программ и отдельных 
частей программ составляют фундамент программирования, так что успех той или 
иной программы в значительной мере определяется тем, насколько хорошо спроек- 
тированы и реализованы ее интерфейсы. В главе 4 рассказывается о том, как эволю- 
ционировала небольшая библиотека для синтаксического анализа популярного 
формата данных. Хотя пример и невелик, в нем иллюстрируются многие важные 
вопросы проектирования программ: абстрагирование, сокрытие данных, управление 
ресурсами, обработка ошибок. 

Как бы мы ни старались написать программу безошибочно с первой же попытки, 
все же возникновение ошибок в ней неизбежно. В главе 5 излагаются общая стратегия 
и тактические приемы, помогающие отлаживать программы и исправлять ошибки 
более систематически и эффективно. Среди рассмотренных в этой главе тем — формы 
проявления типичных ошибок и анализ статистики, позволяющий выявить источник 
проблемы по некоторым типичным шаблонам в отладочных выходных данных. 

Тестирование представляет собой попытку дать достаточное доказательство того, 
что программа работает правильно и остается правильной по мере ее доработки. 
Поэтому в главе 6 мы сосредоточимся на вопросах тестирования — как выполняемо- 
го вручную, так и автоматизированного. Например, потенциально опасные или сла- 
бые места в программах можно обнаружить проверкой граничных условий. С помо- 
щью различных средств автоматизации (наподобие специально написанных для это- 
го программ или сценариев) можно легко выполнить большие объемы тестов 
сравнительно небольшими усилиями. Совершенно другая типичная разновидность 
тестирования, предназначенная для выявления других видов ошибок, называется 
стрессовым тестированием и также рассматривается в этой главе. 

Компьютеры стали такими быстрыми, а компиляторы — настолько качественны- 
ми, что многие программы вполне удовлетворяют требованиям к их быстродействию 
с первого же дня их работы. Но бывают и программы, работающие слишком медлен- 
но или потребляющие слишком много памяти, а некоторые из них отличаются сразу 
обоими этими недостатками. В главе 7 представлен систематический подход к 
эффективной организации ресурсов, используемых программой, который позволяет 
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сохранить правильность и рациональность организации программы в ходе оптими- 
зации ее работы. 

В главе 8 рассматриваются вопросы переносимости. Действительно успешные 
программы существуют достаточно долго, так что их выполняющая среда успевает 
неоднократно измениться. Может также возникнуть необходимость переноса таких 
программ на новую аппаратную платформу, в новую операционную или языковую 
среду. Хорошая переносимость программы в этом контексте означает минимум 
труда и времени, которые необходимо затратить на ее приспособление к новой среде. 

В программировании существует множество языков, причем не только языков 
общего назначения, используемых для реализации разнообразных универсальных 
задач, но и узкоспециализированных, предназначенных для ограниченной области 
приложений. В главе 9 демонстрируется важность знаковых систем или систем обо- 
значений, которые можно использовать для упрощения программ, структуризации 
стоящих перед программистом задач и даже для написания программ, которые сами 
способны генерировать другие программы. 

Говоря о программировании, поневоле приходится демонстрировать большие 
объемы кода. Большинство примеров кода было написано специально для этой кни- 
ги, и лишь некоторые небольшие фрагменты заимствованы из других источников. 
Мы приложили все усилия к тому, чтобы этот код был качественным, и протестиро- 
вали его в пяти-шести системных средах непосредственно в электронной форме. 
Более подробную информацию об этом можно найти на Међ-сайте, посвященном 
данной книге: 


БЕЕр: //Ерор.ам1.сом 


Большая часть приведенных примеров написана на языке С; имеется некоторое 
количество кода на С++ и ]ауа, а также совсем небольшие фрагменты на языках раз- 
работки сценариев. На самом низком уровне организации кода языки С и С+- почти 
ничем не отличаются, так что программы на С являются в то же время и программа- 
ми на С++. Языки С++ и Јауа являются прямыми потомками С, поэтому в значи- 
тельной мере совпадают с ним по синтаксису и предлагают столь же эффективные 
и выразительные средства, в то же время обладая более развитыми наборами типов и 
библиотек. В нашей повседневной работе мы широко используем все три языка, 
а также множество других. Выбор языка зависит от конкретной задачи: операцион- 
ные системы лучше всего писать на скоростном высокоэффективном языке, лишен- 
ном всяких ограничений, таком как С или С++; короткие одноразовые задачки пре- 
красно решаются с помощью языков разработки сценариев или командных интер- 
претаторов наподобие Аук или Рет]; для реализации пользовательских интерфейсов 
практически нет равных языкам Уіѕиа! Ваѕіс, ТсІ/ТК и Јаха. 

Выбор языка для примеров представляет собой нетривиальную методическую 
задачу. Точно так же, как ни один язык не может справиться со всеми задачами оди- 
наково хорошо, нельзя и проиллюстрировать все темы программирования на одном 
и том же языке с одинаковой выразительностью. Языки высокого уровня непосред- 
ственно диктуют программисту ряд технических решений. На более низком уровне 
необходимо выбирать между альтернативными подходами к решению. Учитывая 
больше деталей, можно обсудить вопрос более подробно. Опыт показывает, что даже 
если мы пользуемся только средствами языков высокого уровня, всегда бывает 
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полезно знать, как они соотносятся со средствами более низкого уровня. Не обладая 
этими знаниями, легко наткнуться на непреодолимый барьер в виде непонятного 
поведения программы или необъяснимого падения быстродействия. Поэтому для 
наших примеров мы часто выбирали С, хотя на практике предпочли бы какой- 
нибудь другой язык. 

Тем не менее в основном наше изложение можно считать независимым от кон- 
кретного языка программирования. Выбор структуры данных диктуется тем языком, 
который есть “под рукой”; одни языки не предоставляют почти никакого выбора, 
тогда как другие предлагают широкий круг альтернатив. Но критерии, в соответст- 
вии с которыми делается выбор, должны оставаться одними и теми же. Так, мелкие 
подробности процедур тестирования или отладки в разных языках сильно отлича- 
ются, а вот стратегия и тактические приемы практически одинаковы. Большая часть 
способов и рекомендаций, как сделать программу эффективнее, одинаково приме- 
нима во всех языках. 

На каком бы языке ни писал программист, его задача состоит в том, чтобы 
выжать максимальный эффект из имеющихся у него в наличии средств. Хороший 
программист способен перебороть недостатки как неуклюжего языка, так и непово- 
ротливой операционной системы. В то же время даже самая лучшая среда програм- 
мирования не спасет плохого программиста. Мы надеемся, что эта книга поможет 
вам программировать лучше и получать больше удовольствия от этой работы неза- 
висимо от нынешнего уровня вашей квалификации. 

Мы хотели бы выразить искреннюю благодарность нашим друзьям и коллегам, 
которые прочитали рукопись книги и высказали множество ценных советов и пожела- 
ний. Джон Бентли (]оп Веріеу), Расс Кокс (Киѕѕ Сох), Джон Лакош (]оВп ГаКо$), 
Джон Линдерман (Јоһь Тлю4егтап), Питер Мемишьян (Ребег Метіѕћіап), Ян Лэнс 
Тейлор (Тар Гапсе 'Тау]ог), Ховард Трики (Но\уагА Тгіскеу) и Крис Ван Вик (Сһтіѕ Уап 
МГУЮ) прочли рукопись, причем неоднократно, с необыкновенной тщательностью и 
дотошностью. Мы испытываем глубокую признательность к таким людям, как Том 
Карджилл (Тот Саге), Крис Клиленд (Сһгіѕ Сеат), Стив Дьюхерст (Ѕіеүе 
Юеҹһигѕі), Эрик Гросс (Егіс Стоз$е), Эндрю Херрон (Ап4гем Неггоп), Джерард 
Хольцман (Сегагі Ноіхтапп), Даг Макилрой (Доиё МсПгоу), Пол Макнами (Раш 
МсМатее), Питер Нельсон (Реег Мебоп), Деннис Ритчи (Юеппіѕ Кисые), Рич 
Стивенс (Вісһ Ѕќеуепѕ), Том Шимански (Тот ЗхутапзК!), Кентаро Тояма (Кещаго 
Тоуата), Джон Уэйт (]оБп Маі), Дэниел Ван (Раше! С. Мапе), Питер Вайнбергер 
(Реѓег ҰеіпБегеег), Маргарет Райт (Маграгее \/ 16) и Клифф Янг (СШ Уоипэ), за их 
бесценные комментарии на различных стадиях производства книги. Мы также 
благодарим за добрый совет и вдумчивые предложения таких лиц, как Эл Ахо (АІ Аһо), 
Кен Арнольд (Кеп Агпо4), Чак Бигелоу (СБаск В1вею\), Джошуа Блох (]озбиа 
ВІосһ), Билл Кафрэн (ВШ Соцећгап), Боб Фландрена (ВоЬ Еарігепа), Рене Франш 
(Кепєе Етепсһ), Марк Керниган (Магк Кегиерап), Энди Кёниг (Апау Коеше), Сэйп 
Мюллендер (баре МиПепаег), Эви Немет (Еуі Метеёћ), Марти Рабинович (Магу 
ВаБбіпоҳіх), Марк Шэйни (Магк У. ЗБапеу), Бьорн Страуструп (Вјагпе Ѕігоиѕігир), 
Кен Томпсон (Кеп Тһотрѕоп) и Фил Уодлер (РЫ \/а4ег). Спасибо всем вам! 


Брайан Керниган 


Роб Пайк 
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От издательства 


Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим 
ваше мнение и хотим знать, что было сделано нами правильно, что можно было 
сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно 
услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес. 
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумажное 
или электронное письмо, либо просто посетить наш \/еБ-сервер и оставить свои заме- 
чания там. Одним словом, любым удобным для вас способом дайте нам знать, нравится 
или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги 
более интересными для вас. 

Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, 
а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и 
обязательно учтем его при отборе и подготовке к изданию последующих книг. 
Наши координаты: 

Е-тай: іпЁо@мі11іатѕрир1іѕһіпд. сот 
үүүүүү: Һер: / /мми .м1111атзрур11 56119. сот 
Информация для писем из: 


России: 115419, Москва, а/я 783 
Украины: 03150, Киев, а/я 152 


Стиль программирования 


Давно замечено, что лучшие писатели часто пренебрегают законами 
литературной стилистики. Правда, в каждом случае подобного нарушения 
читатель обычно получает компенсацию в виде других достоинств литера- 
турного произведения. Если же писатель не уверен, что он может 
предложить что-то взамен, ему лучше придерживаться общих правил стиля. 


Уильям Странк, Э.Б. Уайт. “Основы стилистики” 
(Мат 5ёгинЕ, Е.В. Уйие, Тһе Е]етепе$ оё Зе) 


Вот фрагмент кода, взятый из одной большой программы многолетней давности: 


1Е (соцпЕку $16) || (сочпЕку == ВВМГ) || 
(соцпЕку == РОШ) || (соцпёку == ТТАБУ) 
/* 
* 


Если страна - Сингапур, Бруней или Польша, 
то ответом будет текущее время, а не 

* записанное. 

* Переустанавливаем время и день недели. 


ый 


ж 


Этот фрагмент написан, отформатирован и прокомментирован достаточно тща- 
тельно. Да и программа, из которой он взят, работает исключительно хорошо. 
Программисты, которые ее написали, могут по праву гордиться своим творением. 
Но данный отрывок все же малопонятен. Какая связь между Сингапуром, Брунеем, 
Польшей и Италией? Почему Италия не упоминается в комментариях? Раз коммен- 
тарий и код не согласованы, что-то из них должно быть неправильным (возможно, 
ито и другое). Код обычно тестируется и запускается на выполнение, поэтому пра- 
вильным скорее является он, а не комментарий. Возможно, комментарий просто 
вовремя не обновили при исправлении кода. В комментарии недостаточно говорится 
о связи между тремя упоминаемыми странами; если этот код придется дорабатывать, 
нужно будет узнать об этой связи побольше. 

Приведенные несколько строк достаточно типичны для реального кода: в основ- 
ном все написано правильно, но еще есть над чем поработать в плане улучшения. 

Наша книга посвящена практическому программированию — как писать реаль- 
ные, практические программы. Наша цель — помочь вам разрабатывать программы, 
работающие по крайней мере так же хорошо, как та, из которой взят пример, при 
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этом избегая сомнительных или потенциально опасных конструкций. Поговорим о 
том, как же написать хороший код с самого начала, а потом еще и улучшить его по 
мере доработки. Тем не менее начнем мы с не совсем обычной стартовой точки — 
стиля программирования. Предназначение стиля программирования состоит в том, 
чтобы сделать программу легкой для чтения ее автором и другими программистами. 
Хороший стиль играет решающую роль для достижения хорошего качества про- 
грамм. Мы обсудим вопросы стиля в самом начале, чтобы читатель имел совершенно 
ясное понятие об этом при чтении всех последующих глав. 

Чтобы написать программу, недостаточно просто соблюсти требования синтаксиса, 
исправить ошибки и добиться нужного быстродействия. Программы предназначены 
для чтения не только компьютерами, но и программистами. Хорошо написанную про- 
грамму легче читать и дорабатывать, чем плохо написанную. Соблюдение стилистиче- 
ской дисциплины дает большую вероятность, что написанный код окажется семанти- 
чески правильным. К счастью, научиться этой дисциплине совсем несложно. 

Принципы стиля программирования основаны на здравом смысле и практиче- 
ском опыте, а не на взятых с потолка правилах и предписаниях. Код должен быть 
простым и понятным; в нем должны присутствовать такие черты, как очевидность 
логики, естественные выражения, типовые конструкции языка, понятные имена, 
аккуратное форматирование, содержательные комментарии. Хитроумных трюков и 
необычных конструкций следует избегать. Важно соблюдать однородность, посто- 
янство стиля, чтобы другим программистам было нетрудно разобраться в вашем 
коде, а вам — в их программах. Это будет легче сделать, если соблюдается единство 
стиля. Правила стилистики часто задаются принудительно — директивными указа- 
ниями свыше или принятым в организации стандартом. Но даже если это не так, 
всегда лучше соблюдать некий общепринятый стандарт. В этой книге мы придержи- 
ваемся стиля, описанного в книге Язык программирования С (Тһе С Ргортаттіпр 
Тапвиаве), с некоторыми незначительными поправками для языков С++ и Јаха. 

Законы стилистики часто будут иллюстрироваться на небольших примерах пло- 
хого и хорошего стиля, поскольку контраст между тем, как надо и как не надо 
писать, весьма поучителен. Эти примеры не взяты с потолка. Так, примеры “как не 
надо писать” адаптированы из реального кода, написанного обычными программи- 
стами (иногда и нами самими) в условиях прессинга, когда нужно было сделать 
слишком много работы за слишком короткое время. Некоторые из примеров сокра- 
щены для удобства, но содержание их ни в коем случае не искажается. Затем приме- 
ры переписываются в другой форме, чтобы продемонстрировать пути их усовершен- 
ствования. Но поскольку эти фрагменты взяты из реального кода, они могут содер- 
жать несколько уровней или классов ошибок и недоработок. Обсуждение и 
исправление всех этих недостатков заняло бы слишком много места и времени, по- 
этому даже в примерах “как надо писать” могут по-прежнему скрываться проблемы. 

Чтобы отличать плохие примеры от хороших, по всей книге мы сопровождаем 
строки некачественного кода вопросительными знаками на полях, как в этом отрывке: 
? НаеЕ1пе ОМЕ 1 


? #аеЁ1пе ТЕМ 10 
2 #АаеЕ1пе ТИЕМТУ 20 


Раздел 1.1 Имена 17 


В чем же сомнительность данного фрагмента? Подумайте о модификациях, кото- 
рые придется внести в код, если массив из ТМЕМТУ элементов необходимо будет 
удлинить. Уж по крайней мере стоило бы заменить каждое из символических имен 
на такое, которое обозначало бы роль соответствующей константы в программе: 

#дӢеҒіпе ІМРОТ МОРЕ 1 


НаеЕ1пе ТМРОТ ВОЕРЗТОЕ 10 
#аеғіпе ООТРОТ ВОЕЅІ7Е 20 


1.1. Имена 


Какой смысл заключен в именах, или идентификаторах? Имя переменной или 
функции обозначает некий объект и должно нести информацию о предназначении 
этого объекта. Имя должно быть содержательным, кратким, легко запоминающимся, 
а если возможно, то и легко произносимым. Много информации можно извлечь из 
контекста и области действия имени; поэтому, чем шире область действия, тем под- 
робнее должно быть имя. 


Пользуйтесь длинными, содержательными именами для глобальных объектов 
и короткими — для локальных. По определению глобальные имена могут использо- 
ваться в любом месте программы, поэтому они должны иметь достаточно описатель- 
ные и длинные имена, чтобы напоминать читателю об их назначении. Объявление 
каждого глобального имени полезно сопровождать кратким комментарием: 


116 препаіпо = 0; // текущая длина входной очереди 


Глобальные функции, классы и структуры также должны иметь описательные 
имена, отражающие их роль в программе. 

В противоположность этому для локальных переменных подходят и короткие 
идентификаторы. Например, для локальной переменной внутри функции имени п 
вполне достаточно, проіпеѕ — тоже неплохо, а вот потрегоЁРоіпеѕ — уже явный 
перебор. 

Локальные переменные, используемые стандартным образом, вполне могут 
иметь очень короткие имена. Например, традиционно счетчики циклов обозначают- 
ся і и ј, указатели — р и а, а строки — зи ©. Используя вместо этих обозначений 
более длинные, можно не только ничего не выиграть, но даже проиграть. Рассмот- 
рим такой пример: 


Э Ғор (ЕреЕ1етепеТпаех = 0; +ВеЕ1етепеТпаех < питрехгоЕЕ1етептез; 
? СВеЕ1етеп® Тпаех++) 
? е1етепёАггау [Е реЕ1етепЕТпаех] = ёһҺеЕ1етепёІпаех; 


А теперь перепишем его в следующем виде: 


Ғор (і = 0; і < пе1етѕ; 1++) 
е1ем[і] = 1; 


Программистов часто приучают применять длинные имена вне зависимости от 
контекста. Это ошибка — удобочитаемость часто достигается именно краткостью 
записи. 
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Существует много стандартов именования и различных местных обычаев. Среди 
самых распространенных — использование имен указателей, начинающихся или 
заканчивающихся на р (таких как поаер); написание идентификаторов с прописных 
букв (С1ора1ѕ); написание имен прописными буквами (СОМ5ТАМТ$). В некоторых 
организациях используются более сложные системы, например, способы кодирова- 
ния в имени переменной ее типа и употребления. В этом случае рсһ может значить 
указатель на символ (сокращение от ройиег-ю-срагасег), а зехТо и зесЕгом — 
строки, используемые соответственно для записи и чтения. Что касается сокраще- 
ний и сочетаний внутри имен, то выбор между препа1та, пашРепа1па или 
пит репаӣіпо является делом вкуса. Не так важна конкретная система правил, как 
единообразие стиля и его постоянная привязка к некоему разумному стандарту. 

Следование соглашениям об именовании помогает лучше понимать как свой собст- 
венный код, так и написанный кем-то другим. Наличие стандарта позволяет легко 
придумывать новые имена по мере дописывания программы. Чем длиннее программа, 
тем важнее становится выбор качественных, содержательных, систематических имен. 

Пространства имен в С++ и пакеты в Јауа позволяют управлять областью дейст- 
вия имен и поддерживать их удобочитаемость без необходимости придумывать 
слишком длинные идентификаторы. 


Соблюдайте единообразие и согласованность. Аналогичным или родственным 
объектам нужно давать аналогичные имена, которые бы демонстрировали родство и 
подчеркивали различие. 

В следующем классе ]ауа имена не просто слишком длинные, они еще и совер- 
шенно не согласованы между собой: 
с1аѕѕ Чзегоцеце { 


іп поОЕТеетзтТпО, ЕгопеОЕТБебцеце, ацецеСарас1®у; 
роир1іс іп пооЕОзегзТпОцеие() {...} 


? 
? 
? 
? 

Слово “ацеце” (“очередь”) фигурирует в идентификаторах как О, Оцеце и ачеце. 
Но, поскольку обращение к очередям все равно возможно только через переменные 
типа ОзехОцеце, в именах членов этого класса вообще не нужно упоминать слово 


“ацеце”. Вполне достаточно контекста. Например, следующая запись несет избыточ- 
ную, дублирующуюся информацию: 


? ачече .дачецесарасіѓёу 
Вот такая версия объявления класса намного лучше: 


с1аѕѕ ОѕегоОцеце { 
106 пібетѕ, ЕхопЕ, сарасіѓёу; 
рирІіс іпё поиѕегрѕ() {...} 


В этом случае операторы работы с очередью будут записываться удобнее: 


ачеце.сарасііу++; 
п = ачеце.пазетз (); 
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Смысл объявляемых переменных остался полностью понятным. Тем не менее и в 
этом случае еще есть над чем работать. По сути, ісетѕ (“элементы”) и изегз 
(“пользователи”) в данном классе обозначают одно и то же, поэтому следовало бы 
употребить только один из этих синонимов. 


Давайте функциям активные имена. Желательно, чтобы имя функции содер- 
жало активный глагол — возможно, с последующим существительным. Например: 


пом = Чдабе.аееТ1те(); 
раесрах ('\п'); 


Функции, возвращающие логические значения (ИСТИНА или ЛОЖЬ), должны но- 
сить такие имена, чтобы было однозначно понятно, в каком случае возвращается ка- 
ждое из возможных значений. Например, в этой записи непонятно, когда возвраща- 
ется ИСТИНА, а когда — ЛОЖЬ: 


? 1Е (сһескосіёа1 (с)) 


Дадим этой функции другое имя: 


1Е (іѕосіёа1 (с)) 


Теперь ясно, что функция возвращает значение ИСТИНА, если ее аргумент явля- 
ется восьмеричным, и ЛОЖЬ в противоположном случае. 


Будьте пунктуальны. Имя не только обозначает объект, оно еще и несет 
информацию читателю. Дезориентирующее имя может помешать программисту 
найти в программе ошибку. 

Один из авторов в свое время написал макрос под названием іѕосба1, который 
много лет распространялся в составе библиотек языка С: 


? #аеЁ1пе іѕосёа1 (с) ((с) >= '0' && (с) <= '8!) 


В этом макросе есть ошибка. Правильно было бы написать так: 


#АеЁЕ1пе іѕосіа1 (с) ((с) >= '0' && (с) <= !'7!) 


В данном случае имя макроса правильно выражает намерение автора, но его реа- 
лизация оказалась ошибочной. Разумный выбор имени объекта запросто может 
скрыть от внимания разработчика недоработки в самом объекте. 

Вот пример, в котором имя и код метода находятся в противоречии друг к другу: 
рор1іс Боо1еап іпТар1е (Орјесё оЬј) { 
іпё ј = 6015 .чееТпаех (орј); 
тебихп (ј == пТар1е); 


} 


Функция деІпдех возвращает значение из диапазона от 0 до пТар1е-1, если 
она находит объект в таблице, и значение пТар1е, если не находит. Таким образом, 
декларируемое логическое значение, которое возвращает функция іпТар1е, на 
самом деле выражает совсем не то, что подразумевается ее именем. Во время напи- 
сания программы с участием этой функции, возможно, ничего страшного не про- 
изошло, но если впоследствии кто-то другой решит доработать программу или ис- 
пользовать ее, имя функции наверняка вызовет путаницу. 
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Упражнение 1.1. Прокомментируйте выбор имен и значений в следующем 
фрагменте кода: 


? НаеЁ1пе ТВОЕ 0 


? #аеЕ1пе РАТЗЕ 1 
р 
? 1Е ((сһ = деесвВак()) == ЕОЕ) 
Э по еоЁ = ҒАІЅЕ 
Упражнение 1.2. Доработайте эту функцию: 
? 116 ѕта11ег (сһаг *5, сһаг *®) { 
? 1Е (з6хспр (8, ©) < 1) 
Е хегиев 1+ 
2 е1ѕе 
? геіџгп 0; 
? } 
Упражнение 1.3. Прочитайте этот код вслух: 
2 1Е ((Еа11ос ($МВН$Н$СВТСН, $_ТЕЕХТ | 0644, МАХРОРрнѕн)) < 0) 
? ... 


1.2. Выражения и операторы 


По аналогии с тем, как следует выбирать идентификаторы для лучшего понимания 
программы, выражения и операторы тоже необходимо составлять так, чтобы по воз- 
можности исключить сложность или двусмысленность восприятия. Из всех вариантов, 
которые решают поставленную задачу, выбирайте самый понятный. Для группировки 
операндов окружайте знаки операций пробелами; или, обобщая эту рекомендацию, 
используйте визуальное форматирование для улучшения удобочитаемости. Это про- 
сто, но очень полезно, наподобие того, как чисто убранный рабочий стол позволяет 
легко находить на нем нужные вещи. Но рабочий стол — это ваше личное дело, а вот 
написанные вами программы скорее всего будут читать другие люди. 


Структурируйте операторы с помощью отступов. Последовательное и 
логичное применение отступов — это способ сделать структуру программы проще 
и очевиднее ценой самых минимальных усилий. Ниже приведен пример плохого 
форматирования кода. 


? Еох (п++;п<100; Ғіе1а [п++] ='\0'); 
? *1 = '\0'; геёџгп('\п'); 


Попробуем несколько улучшить читаемость этого фрагмента, переформатиро- 
вав его: 


Бог (п++; п < 100; Е1е1а[п++] = '\0') 
жі = '\0'; 


? 
? 
? 
? геёцгп ('\п'); 
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Еще лучше будет поместить присваивание в тело цикла и отделить инкременти- 
рование счетчика, чтобы цикл принял более стандартную форму и стал понятнее при 
чтении: 

Ғор (п++; п < 100; п++) 
Ғіе1а [а] = '\0'; 

жі = '\0'; 

геёигп ('\п'); 


Записывайте выражения в естественной форме. Следует писать выражения 
так же, как бы вы читали их вслух. Условные выражения, содержащие операцию 
отрицания, всегда труднее понять: 


? 1Е (! (р1оск іа < асёь1кв) || !(р1оск іа >= ипЬ1оскз)) 
? = 


Каждая из проверок в условии записана в форме отрицания, хотя в обоих случаях 
для этого нет никакой необходимости. Сделаем все наоборот и построим утверди- 
тельную форму обеих проверок: 


1Е ((р1оск іа >= асёр1кѕ) || (р1оск іа < ипр1оскз)) 


Теперь КОД ВЫГЛЯДИТ более естественно. 


Используйте скобки во избежание двусмысленности. Скобки существуют для 
того, чтобы группировать операнды. С их помощью можно более явно обозначить 
выполняемую операцию даже тогда, когда синтаксис этого не требует. В предыду- 
щем примере внутренние скобки необязательны, однако и вреда от них никакого. 
Бывалые программисты, наверное, опустили бы эти скобки, потому что операции 
сравнения (< <= == != >= >) имеют более высокий приоритет, чем логические опе- 
рации (&& и ||). И все же при совместном использовании операций с различным 
приоритетом лучше не жалеть скобок. Язык С и его “родственники” чреваты опас- 
ными ошибками, возникающими из-за приоритета операций. Такие ошибки сделать 
легко, а обнаружить трудно. Поскольку логические операции представляют более 
тесную связь между операндами, чем оператор присваивания, скобки обязательны 
практически во всех выражениях, где эти знаки используются совместно: 


мһі1е ((с = деёсһаг()) != ЕОЕ) 


Поразрядные двоичные операции & и | имеют более низкий приоритет, чем 
операции сравнения наподобие ==, так что не обманывайтесь внешним видом 
следующего выражения: 


? 1Е (х&МАЗК == ВІТЅ) 
? 

Это выражение означает не то, что можно подумать из-за пространственной 
группировки операндов, а нечто другое: 


? 1Е (х & (МАЅК == ВІТЅ)) 
? Ар 
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А это явно не входило в намерения программиста. Поскольку в выражении соче- 
таются поразрядные операции и операции сравнения, необходимо использовать 
скобки: 


1Е ((Х&МАЅК) == ВІТ) 


Даже если в скобках нет необходимости, они могут помочь сориентироваться 
втаком выражении, группировка операндов в котором не ясна с первого взгляда. 
Например, в следующем фрагменте синтаксис языка не требует применения скобок: 


? 1еар уеаг = у % 4 == 0 && у $ 100 != 0 || у 400 == 0; 


Тем не менее скобки делают выражение более удобочитаемым: 


1еар уеаг = ((у % 4 == 0) && (у % 100 != 0)) || (у % 400 == 0); 


В последнем выражении по сравнению с первоначальным удалось также убрать 
некоторое количество пробелов. Группировка операндов, относящихся к операциям 
с высоким приоритетом, помогает лучше рассмотреть структуру всего выражения. 


Разбивайте сложные выражения на части. Языки С, С++ и ]ауа обладают 
развитым синтаксисом выражений, поэтому программисты часто соблазняются воз- 
можностью “впихнуть” в одно выражение побольше операций. Например, следую- 
щее выражение довольно компактно, однако для одного оператора в нем слишком 
много составных элементов: 


? *х += (*хр=(2*К < (п-т) ? с[к+1] : а[К--])); 
Это выражение воспринимается лучше, если разбить его на несколько частей: 


1Е (2%*К < п-т) 
*хр с[К+1]; 
е1 зе 
*хр = а[к--]; 
*х += *хр; 


Выражайтесь как можно понятнее. Программисты прилагают нескончаемые 
усилия, чтобы написать как можно более краткий код или изобрести самый остро- 
умный способ достичь нужного результата. Правда, часто эти усилия направлены не 
на ту цель — ведь необходимо писать самый понятный, а не самый изощренный код. 

Вот, например, какую операцию выполняет этот хитроумный оператор? 


? ѕоркеу = варкеу >> (Ь1еоЕЁ - ((Ъ160оЕЕЁ >> 3) << 3)); 


Во внутреннем выражении значение рісоЁ# сдвигается на три бита вправо. 
Затем результат сдвигается влево, и тем самым три сдвинутых бита заменяются ну- 
лями. Этот результат вычитается из исходного значения, и все это в итоге дает три 
младших бита переменной Ъ1ЕоЕЕ. Полученные три бита используются для сдвига 
переменной заЪКеу вправо. 

Таким образом, первоначальное выражение эквивалентно следующему: 


зарКеу = ѕиркеу >> (рісоЁї & 0х7); 
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Некоторые конструкции, кажется, просто обречены на злоупотребление. Именно 
такова операция выбора по условию ?:, с помощью которой можно построить 
довольно загадочные выражения: 


2 сһі1а= (11С&&! ВС) ?0: (!1С?ВС:ІС); 


Почти невозможно догадаться, что же все-таки делает этот оператор, пока не про- 
следишь все возможные альтернативы выбора. Следующая форма значительно 
длиннее, но понять ее гораздо легче, потому что эти альтернативы более очевидны: 

іЁ (1С == 0 && ВС == 0) 
сҺһі1а = 0; 

е1ѕе 1Е (1С == 0) 
сһі1а = ЕС; 

е1ѕе 
сһі1а = 1с; 


Операция ?: хороша для коротких выражений, в которых она может заменить 
три-четыре строки операторов і#-е1ѕе. Вот пример: 


шах = (а > Ь) ? а : ЬЫ; 


И еще один пример: 


ре1пЕЕ ("Тһе 1іѕі раз %а ібет%ѕ\п", п, п==1 ? "" : "5"); 


Но в целом операцию выбора по условию нельзя считать равноценным замените- 
лем условного оператора. 

Понятность кода — это совсем не то же самое, что его краткость. Довольно часто 
более понятный код является в то же время и более кратким — как, например, в при- 
веденном выше операторе со сдвигом. С другой стороны, он может быть и более 
длинным, как в примере с заменой операции выбора по условию операторами 
1Е-е1 зе. Единственным критерием выбора тут является легкость понимания кода. 


Учитывайте возможные побочные эффекты. Такие операции, как инкремен- 
тирование ++, имеют побочные эффекты: кроме возвращения определенного значе- 
ния, они еще и изменяют значение своего аргумента. Эти побочные эффекты бывают 
очень удобны, однако из-за них могут также возникнуть проблемы, поскольку опе- 
рации извлечения значения и модификации переменной иногда не совпадают по 
времени. В языках С и С++ порядок выполнения операций, составляющих побочные 
эффекты, не определен, поэтому при множественном присваивании результат может 
оказаться неправильным: 


? зЕх [1++] = зб [1++] =' 1; 


В намерения программиста входило помещение пробелов в следующие две пози- 
ции массива зе. Но в зависимости от того, когда модифицируется индекс і, одна из 
позиций зЕх может оказаться пропущенной, и индекс в итоге увеличится только на 
единицу, а не на два. Следует разбить этот оператор на две части: 


ЗЕЕ [1++] = т: 
Ех [1++] = ; 


1 


| 
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Даже если оператор содержит всего одно инкрементирование, он все равно может 
дать непредсказуемый результат. Рассмотрим следующий пример: 


? аггау [1++] = і; 


Если, например, вначале переменная 1 была равна 3, то элемент массива может 
получить значение как 3, так и 4. 

Побочными эффектами обладают не только операции инкрементирования и дек- 
рементирования. Еще один источник скрытых проблем — это операции ввода- 
вывода. Вот пример попытки чтения двух взаимосвязанных значений из стандартно- 
го потока ввода: 


? зсапЕ ("а %А", куг, &ргоѓіѓ [уг] ); 


Это некорректный оператор, потому что в одной его части переменная уг моди- 
фицируется, а в другой — сразу же используется. Значение ргоѓії [уг] практиче- 
ски не имеет шансов оказаться правильным, разве только в том случае, если старое и 
новое значения уг совпадают. Можно было бы подумать, что результат зависит от 
порядка вычисления аргументов, но проблема-то как раз в том, что все аргументы 
функции зсапЕ вычисляются до ее вызова, т.е. адрес &ргоҒії [уг] всегда вычисля- 
ется с использованием старого значения уг. Подобная проблема может возникнуть 
практически в любом языке программирования. Ее решение, как и в одном из пре- 
дыдущих примеров, состоит в том, чтобы разбить один оператор на два: 


зсапЕЁ ("%А", &уг); 
ѕсап# ("%А", &рхкоЕте [уг] ); 


Следует соблюдать максимальную осторожность при работе с любым выражени- 
ем, содержащим побочные эффекты. 


Упражнение 1.4. Усовершенствуйте все приведенные ниже фрагменты кода. 


а Есе ету аео) ) 

? геіогп; 

? Іепаёһ = (1епдёһ < ВОЕЗСТАЕ) ? 1епдёһ : ВОЕЗТАЕ; 
2 Ета = таб 202: 

? апоБбеч=: ‘(Луне 1") 0: 

? 1Е (уа1 & 1) 

? ріё = 1; 

2 е1зе 

? ріс = 0; 


Упражнение 1.5. Найдите ошибки или недочеты в следующем фрагменте кода: 


іпё геаа (іп *1р) { 
зсапЕ ("%а", ір); 
геёигп *1р; 


} 


іпѕегі (&дгарһ [чегі], геаа (&уа1), геаа (&сһ)); 


БА В о Зе 
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Упражнение 1.6. Перечислите все различные результаты, которые может сгене- 
рировать данный фрагмент кода при разном порядке вычисления выражений: 


? ПЕР 
? ре1пЕЁ ("а %а\п", п++, п++); 


Протестируйте этот фрагмент на как можно большем количестве разных компи- 
ляторов, чтобы посмотреть, что же может произойти на практике. 


1.3. Единообразие стиля и устойчивые 
конструкции 


Соблюдение единообразного стиля позволяет писать программы более высокого 
качества. Если форматирование кода непредсказуемо меняется от одного блока к 
другому, или перебор массива в цикле выполняется то в одном, то в другом порядке, 
или строки копируются один раз функцией зЕгсру, а другой раз — в цикле Еох, то 
все эти вариации очень сильно мешают правильному восприятию программы и по- 
ниманию того, что же она действительно делает. А вот если одна и та же вычисли- 
тельная операция выполняется каждый раз одинаково, то какие-либо отличия появ- 
ляются только в том случае, если изменяется и сам характер выполняемых вычисле- 
ний, что позволяет легко привлечь внимание программиста. 


Используйте единую систему отступов и расстановки фигурных скобок. 
Отступы призваны наглядно демонстрировать структуру программы. Какой же 
стиль абзацного отступа наилучший? Следует ли ставить открывающую фигурную 
скобку в той же строке, что и оператор 1Е, или в следующей? Программисты посто- 
янно спорят о форматировании исходного кода, но сам по себе стиль не так важен, 
как его строгое и последовательное соблюдение. Выберите один стиль (лучше 
всего — наш), придерживайтесь его во всех своих программах, и хватит тратить 
время на ненужные споры. 

Следует ли ставить фигурные скобки в том случае, если синтаксис этого не тре- 
бует? Дополнительные фигурные скобки, как и квадратные, могут помочь устранить 
двусмысленность и сделать код понятнее. Для единообразия стиля многие програм- 
мисты всегда заключают тела циклов или операторов 1 в скобки. Если тело состоит 
из одного оператора, то в скобках нет необходимости и их часто опускают. Если вы 
также опускаете лишние скобки, то по крайней мере сохраняйте их в том случае, 
когда они необходимы для разрешения неоднозначности “висячего” блока е1 зе. 
Эту неоднозначность можно проиллюстрировать на следующем примере: 
1Е (топЕВ == РЕВ) { 

1Е (уеаг%4 == 0) 
1Е (аау > 29) 
1еда1 = РАІЅЕ; 
е1ѕе 
1Е (дау > 28) 
1едаї = ЕА1ЅЕ; 


о 0 0р0 0 0р0 0 
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В данном случае отступ вводит в заблуждение, поскольку блок е1ѕе на самом 
деле относится к строке 


? 1Е (дау > 29) 


Таким образом, в коде сделана ошибка. В тех случаях, когда один оператор 1Е 
следует сразу за другим, всегда используйте дополнительные скобки: 


? 1Е (топёһ == РЕВ) { 

? 1Е (уеаг%4 == 0) { 

? 1Е (дау > 29) 

? 1еда1 = ЕАЬСЕ; 
? } е1зе { 

? 1Е (ау > 28) 

? 1еда1 = ГАІЅЕ; 
? } 

? 


} 


При использовании специальных редакторов со встроенными средствами анали- 
заи коррекции синтаксиса такие ошибки становятся менее вероятными. 

Хотя ошибка исправлена, читать этот код все еще трудно. Проследить за выпол- 
няемыми вычислениями будет легче, если ввести специальную переменную для хра- 
нения количества дней в феврале: 


1Е (торЕН == РЕВ) { 
106 паау; 


2 

? 

? 

? паау = 28; 

? 1Е (уеаг%4 == 0) 

? паау = 29; 

? 1Е (аау > паау) 

2 Іеда1 = ЕАІЅЕ; 
? 


} 


Получившийся код все еще работает неправильно. Например, 2000 год является 
високосным, тогда как 1900 и 2100 — нет, хотя программа сочтет их високосными. 
Но этот вариант уже гораздо легче довести до полного совершенства, чем предыдущие. 

Кстати, если вы дорабатываете программу, написанную не вами, лучше придер- 
живайтесь того стиля, который вы в ней обнаружите. Внося изменения, не прибегай- 
те к своему собственному стилю, даже если он вам больше нравится. Единообразие 
стиля все-таки важнее, потому что следующим доработчикам после вас так будет 
легче работать. 


Используйте устойчивые конструкции для поддержания единого стиля. 
Как и в человеческих языках, в языках программирования существуют устойчивые 
конструкции (идиомы) — стандартные варианты реализации самых распространен- 
ных операций. Главное в изучении любого языка — это как следует ознакомиться с 
системой его идиом. 

К числу наиболее распространенных идиом принадлежат формы записи циклов. 
Рассмотрим код на языках С, С++ и ]ауа, реализующий перебор массива из п эле- 
ментов. Такой перебор может понадобиться, например, для инициализации этого 
массива. Можно написать нечто подобное: 
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? = 0 
? мһі1е (і <= п-1) 
? агхау [1++] = 1.0; 


Возможен и такой вариант: 


о 


Бог (і = 0; і < п; ) 
? агхау [1++] = 1.0; 


Не исключена также подобная форма записи: 


> 


гоа прера 0) 
? аггау [1] = 1.0; 

Все эти формы правильны, но идиоматической, устойчивой конструкцией явля- 
ется только следующая: 


Ғор (і = 0; і < п; 1++) 
аггау [1] = 1.0; 


Именно эта запись выбрана в качестве идиомы не случайно. Во-первых, в ней по 
очереди перебираются все п элементов массива по порядку от 0 до п-1. Во-вторых, 
все управление циклом сосредоточено в его заголовке. В-третьих, операция выпол- 
няется в естественном порядке — по возрастанию, — причем для приращения счет- 
чика цикла используется такое стандартное, общеизвестное средство, как операция 
инкрементирования. В-четвертых, после выполнения цикла индексная переменная 
остается равной удобному известному значению — количеству элементов в массиве, 
или индексу следующего за последним элемента. Опытные знатоки языка распозна- 
ют эту конструкцию так же мгновенно и без всяких раздумий, как и напишут ее. 

В языках С++ и Јауа широко распространен вариант с объявлением счетчика 
цикла прямо в заголовке: 


Ғор (іп і = 0; і < п; і++) 
аггау [1] = 1.0; 


А вот стандартный цикл для перебора списка в языке С: 


Ғор (р = 1іѕё; р != МЈ; р = р->пехіё) 


И в этом случае все управление циклом сосредоточено в заголовке Ёог. 
Для организации бесконечного цикла мы предпочитаем использовать такую кон- 
струкцию: 


Рот) 


Впрочем, популярностью пользуется и эта форма: 


мһі1е (1) 


Никаких других конструкций, кроме этих двух, использовать не следует. 
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Система абзацных отступов тоже должна быть стандартной, по существу идиома- 
тической. Например, следующая вертикальная (совершенно необычная) запись 
цикла портит все впечатление — вся конструкция кажется вовсе не циклом, а тремя 
отдельными операторами: 

2 Рок 1{ 

2 ар = акк; 

? ар < агг + 128; 
2 *ар++ = 0 

? ) 

2 { 

? 

? } 


Стандартный цикл читать гораздо легче: 


, 


Еог (ар = аүү; ар < агү+128; ар++) 
хар = 0; 


К тому же слишком сильно разнесенный по строкам код не отличается компакт- 
ностью и не помещается на экран или страницу. Это неудобно для его чтения. 

Часто встречается такая устойчивая конструкция, как помещение присваивания в 
условие цикла. Например: 


мһі1іе ((с = деїсһаг()) != ЕОЕ) 
риєсћһаг (с); 


Оператор дӢо-ућі1е используется гораздо реже, чем Ёог или ућі1е, потому что 
он всегда выполняется как минимум один раз еще до проверки своего условия. 
Другими словами, условие проверяется в конце цикла, а не в его начале. Во многих 
случаях эта конструкция представляет собой скрытую ловушку, как, например, в 
этом варианте цикла считывания и записи символов: 


? ао { 

? с = деісћһаг (); 
? росһаг (с); 

? } мые (с != ЕОЕ); 


В поток вывода легко может попасть лишний символ, потому что проверка конца 
файла выполняется после вызова функции роёсһаг. Циклом ао-мћі1е следует 
пользоваться только тогда, когда его тело обязательно должно выполняться хотя бы 
один раз. Позже будут рассмотрены некоторые примеры. 

Одно из преимуществ единообразия в использовании идиом состоит в том, что 
нестандартные (а значит, потенциально ошибочные) циклы сразу привлекают к себе 
внимание: 


? 106 1, *іАггау, птетр; 

Е 

? іАггау = та11ос (пмешь * 512еоЕ (1п6)); 
? Ғор (і = 0; 1 <= птетр; і++) 

? ЇАггау [1] = і; 


При распределении памяти для массива было выделено птеть элементарных 
ячеек — от іАггау [0] до 1Аггау [птетр-1]. Но цикл выполняется от 0 до пмепь, 
так что затирается участок памяти непосредственно после конца массива. К сожале- 
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нию, подобные ошибки часто обнаруживаются только тогда, когда данным уже 
нанесен существенный вред. 

В языках Си С++ имеются устойчивые конструкции для распределения памяти 
под строки и работы с ними. Код, в котором не используются такие конструкции, 
часто бывает написан с ошибками: 


сһаг *р, БаЕ[ 256]; 


аесѕ (ри?) ; 
р = ма11ос (ѕіг1еп (риЁ)); 
ѕсгсру (р, риё); 


о0о у 0 


Функции деез необходимо избегать, потому что нет способа ограничить считы- 
ваемый ею объем данных. Отсюда возникают проблемы безопасности, к которым мы 
вернемся в главе 6. Там мы покажем, что функция Ёде ѕ всегда является лучшим вы- 
бором для подобных операций. Но существует и еще одна проблема: функция ѕёг1еп 
не включает завершающий нуль, '\0', в подсчитанное ею количество символов, тогда 
как ѕзегсру копирует вместе с другими и его тоже. Таким образом, для строки выделя- 
ется недостаточно памяти, и функция зЕгсру выполняет запись за пределами отве- 
денного пространства. Стандартная конструкция выглядит таким образом: 


р = ма11ос (зЕх1еп (риё) +1); 
ѕсгсру (р, риѓ); 


И еще один вариант, на этот разв С++: 


р = пем срах [зе х1еп (риё) +1]; 
ѕсгсру (р, РчЕЁ); 


Если вы пропустили дополнительную единицу (+1), берегитесь! 

В языке Јауа данная конкретная проблема не существует, потому что там строки 
не представляются массивами символов с завершающими нулями. К тому же индек- 
сы массивов подвергаются проверке, поэтому в Јауа нет возможности выйти за пре- 
делы заданных границ массива. 

В большинстве сред программирования на С и С++ имеется библиотечная функ- 
ция ѕегаицр, создающая копию строки с использованием функций та11ос и 
зе хсру. С ее помощью легко избежать описанной ошибки. К сожалению, функция 
ѕігацр не определена в стандарте АМ№І С. 

Кстати, ни первоначальная, ни исправленная версия приведенного примера не 
содержит проверки значения, возвращаемого функцией та11ос. Мы опустили этот 
момент, чтобы сосредоточиться на главном, однако в любой реальной программе 
необходимо проверять значения, возвращаемые из таких функций распределения 
памяти, как та110ос, геа11 ос, зе хацр и др. 


Используйте каскад е1ѕе 1Е для реализации многовариантного выбора. 
Принятие решений в зависимости от нескольких вариантов выбора описывается 
такой идиоматической конструкцией, как цепочка 1Ё ... е1ѕе 1ЁЕ ... е1взе. 
Вот ее общая структура: 
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1Е (условие 1) 
оператор 1 
е1зе 1Е (условие 2) 
оператор 2 


е1ѕе і# (условие п) 
оператор п 

е1ѕе 
оператор по умолчанию 


Условия проверяются сверху вниз. Как только найдено первое выполняющееся 
условие, управление передается следующим за ним операторам, а затем остальная 
часть каскада пропускается. Операторы могут быть одиночными или объединенны- 
ми в блоки — группы в фигурных скобках. 

Последний оператор обрабатывает ситуацию “по умолчанию”, т.е. случай, когда 
не выполняется ни одно из условий. Завершающий блок е1 зе можно опустить, если 
по умолчанию ничего не нужно делать. Правда, его можно и оставить, включив туда 
вывод сообщения об ошибке. Это превентивная мера на случай возникновения 
“невозможной” ситуации, т.е. непредвиденной в программе. 

В такой конструкции следует выровнять все ключевые слова е1ѕе по одной вер- 
тикальной линии, а не ставить их в соответствие операторам 1#. Вертикальное 
выравнивание подчеркивает, что выполняется последовательная проверка, и не дает 
строкам сползать к правому краю страницы. 

Длинный каскад вложенных операторов 1 ЕЁ часто свидетельствует о низком каче- 
стве кода, а то и об откровенных ошибках в нем: 


ТЕ (абас: == 3) 
1Е ((Е1п = Ёореп (арду [1], "г")) != МЈ) 
1Е ((Ғоџё = Ғореп (агау [2], "м")) != МО) { 
мһі1е ((с = дес (Ғіп)) != ЕОР) 


роєс (с, Ёоиб); 
Ес1озе (Ғіп); Ёс1оѕе (Ёооё); 
} е1ѕе 
ргіпії ("Сап'6 ореп оцбриЕ Ё11е %5\п", агу [2]); 
е1ѕе 
ргіпії# ("Сап'Е ореп іпри Е11е %5\п", агду[1]); 
е1ѕе 
ргіпеё ("Оѕаде: ср іприс#і1е оцірибѓЁі1е\п"); 


ИИИ 6°) 


Этот каскад операторов і# требует держать в уме “стек” условий и проверок, 
чтобы в нужных местах доставать из этого стека информацию о выполняемых опе- 
рациях (если мы еще будем в состоянии их вспомнить). Поскольку в каждом случае 
выполняется максимум одна операция, следует воспользоваться системой операто- 
ров е1ѕе 1Е. Если изменить порядок проверок и принятия решений, код станет 
более понятным. Кроме того, удастся устранить некоторую утечку ресурсов, имев- 
шую место в исходном варианте: 


1Е (арас != 3) 
ри1пЕЕ ("Оѕаде: ср іприсғі1е оперу Е11е\п"); 
е1ѕе 1ЕЁ ((Ғіп = Ғореп (агау [1], "г")) == МО) 


ргіпії# ("Сап'Є ореп іприё Е11е %5\п", агау[1]); 
е1ѕе 1Е ((ЕочЕ = Ғореп (арду [2], "м")) == МОШ) { 
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ре1пЕЕ ("Сап'Е ореп очЕрче Ё11е %5\п", ака\у[2]); 
Ғс1оѕе (Ё1п); 
} е1зе 
мр11е ((с = дес (Ғіп)) != ЕОЕ) 
рос (с, Ёоці); 
Ес1ове (Ғіп) ; 
Ес1озе (Ғоиб) ; 


} 


Проверки выполняются одна за другой, пока одна из них не даст положительный 
результат. Затем выполняются соответствующие операторы, и управление перехо- 
дит за пределы последнего е1 ѕе. Общее правило состоит в том, чтобы немедленно 
сопровождать каждое принятое решение соответствующими операциями, если это 
возможно. Говоря более простыми словами, как только сделали выбор — выполните 
какую-нибудь операцию. 

При попытке перенести в новую программу готовый фрагмент кода можно 
столкнуться с весьма компактной и малопонятной записью, например: 


? ѕмієсһ (с) { 

? сазе '-': ѕідп = -1; 

? сазе '+': с = деісһаг(); 

? сазе '.': ргеак; 

? аеЕач1е: 1Е (11541916 (с)) 
г геіцгп 0; 
5 


} 


В этом операторе ѕміїсһ используется хитроумно выстроенная последователь- 
ность операторов, выполняемая “насквозь” для экономии строк. Она не относится к 
стандартным, идиоматическим конструкциям, потому что блоки саѕе должны прак- 
тически всегда заканчиваться операторами ргеак, а редкие исключения из этого 
правила Должны быть прокомментированы. Более традиционное оформление 
оператора ѕміїсһ длиннее, но зато понятнее. 


ѕміёсһ (с) { 
сазе '-': 
ѕідп = -1; 
/* выполняется насквозь */ 
сазе '+': 
с = деесвак(); 
Ьгеак; 
сазе '.!: 
Ьгеак; 
аеЁац1® : 
1Е (11591916 (с)) 
бесит’? 


о0о 00 ор р ро ор ор ор ор 0 


} 


Удлинение кода более чем компенсируется удобством его чтения. И все-таки 
для этой нестандартной конструкции еще лучше подошел бы каскад операторов 
1Е-е1 зе: 


= -1; 
= деёсћһаг (); 


ое! 
Р- 
[е 
5 
| 
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} е1ве 1Е (с == '+') { 

с = аеісћһаг (); 
} е1зе і? (с != '.' && 11891918 (с)) { 
гецгп 0; 


Фигурные скобки вокруг блоков, состоящих из одной строки, подчеркивают 
параллельную структуру алгоритма. 

Сквозной проход через блоки сазе вполне приемлем, если в нескольких блоках 
должны выполняться одни и те же операции. Обычное оформление выглядит так: 


сазе '0': 

сазе '1': 

сазе !2': 
Ьгеак; 


В этом случае дополнительный комментарий не требуется. 


Упражнение 1.7. Перепишите эти фрагменты кода на языке С/С++ в более 
удобной форме: 


? 1Е(1366у (э6а11)) ; 

? е1ѕе 1Е (іѕёбу (=©ёаоці)) ; 

? е1ѕе 1Е (іѕібу (ѕёдӢеуг)) ; 
? е1зе геёцгп (0); 

? 1Е (хебуа1 != 50ССЕЅ5) 

? 

? геёцгп (гебуа1); 

9 } 

? /* Все прошло хорошо */ 

Е. хебакп 50ССЕ$5; 

? Ғог (К = 0; К++ < 5; х += ах) 
? зсапЕЁ ("%1#", &ах); 


Упражнение 1.8. Найдите ошибки в следующем фрагменте кода на языке ]ауа 
и исправьте их, переписав код с применением стандартных конструкций: 


116 сойпе = 0; 
мћі1е (соцпЕе < ёоба1) { 
соцпі++; 
1Е (Еһіѕ.деЕМате (соцпё) == патесар1е.цѕегћате ()) { 
гесигп (ёгоце); 
} 


о о р р р о 0 
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1.4. Макрофункции 


Представители старой школы программирования на С очень любят писать мак- 
росы вместо функций для быстрых и коротких вычислений, которые выполняются 
очень часто. Среди таких макросов имеются даже официально санкционированные 
для целей ввода-вывода (например, дессһаг) или анализа символов (например, 
15491916). Поводом для их написания служит повышение быстродействия — с по- 
мощью макроса можно избежать потерь времени на вызов функции. Но этот аргу- 
мент был не очень убедителен даже в первые годы существования С, когда компью- 
теры работали медленно, а функции вызывались долго; в настоящее время об этом 
вообще смешно говорить. При современном уровне развития вычислительной тех- 
ники и компиляторов недостатки макрофункций с лихвой покрывают то небольшое 
преимущество, которое достигается отсутствием затрат на вызов. 


Избегайте макрофункций. В языке С++ встраиваемые (іп1іпе) функции 
сделали функциональные макросы ненужными. В Јауа макросов нет вообще. Даже в 
своем родном языке С они создают больше проблем, чем решают. 

Одна из наиболее серьезных проблем с макрофункциями состоит в том, что если 
в ее определении несколько раз фигурирует один и тот же параметр, то он может 
вычисляться тоже несколько раз. Если макрофункция содержит операции с побоч- 
ными эффектами, в результате получается трудноуловимая ошибка. Ниже приведен 
пример, в котором реализуется одна из функций анализа символов из заголовочного 
файла <сеуре.В>: 


? #аеЕ1пе 1зиррек(с) ((с) >= 'А' && (с) <= '2') 


Обратите внимание, что параметр с фигурирует в определении макроса дважды. 
А теперь представим, что эта макрофункция вызывается в таком контексте: 


? мһі1е (іѕиррег (с = аеёсћһаг ())) 
Э, 


Теперь всякий раз, когда введенный символ по своему значению больше или 
равен 'А', он будет затираться следующим символом, сравниваемым уже с '2'. 
Стандарт С проработан достаточно тщательно, что позволяет определить іѕиррег и 
другие аналогичные функции как макросы, но только в том случае, если они гаран- 
тируют однократное вычисление аргумента. Поэтому приведенная выше реализация 
не ГОДИТСЯ. 

Всегда лучше пользоваться готовыми функциями из файла сеуре, чем писать их 
самому. В целях безопасности следует также избегать вложенных функций типа 
сессһаг, имеющих побочные эффекты. Перепишем анализ символа с использова- 
нием двух выражений вместо одного. Кроме всего прочего, это позволит еще и 
не пропустить возможную ситуацию конца файла: 


мһі1е ((с = аеісһаү()) != ЕОР && 1виррег(с)) 
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Иногда многократное вычисление выражения или аргумента приводит к просто- 
му ухудшению быстродействия, а не к явной ошибке. Например: 


? #аеЕ1пе ВООМО То_ТМТ(х) ((іпс) ((х) + (((х) >0)?0.5:-0.5))) 
? 


? ѕіле = КООМО ТО ІМТ (заг® (ах*ах + ау*ау)); 


В этом фрагменте кода квадратный корень вычисляется вдвое чаще, чем это 
необходимо. Такое сложное выражение, как тело макроса ВООМЮ ТО ІМТ, пусть да- 
же с простым аргументом, транслируется в длинную последовательность инструк- 
ций, которую следовало бы поместить в отдельную функцию и вызывать по мере 
необходимости. Подстановка макрофункции во все места, в которых она вызывается, 
делает итоговую скомпилированную программу длиннее. (Встраиваемые функции 
С++ тоже имеют этот недостаток.) 


Заключайте в скобки тело макрофункции и ее аргументы. Если все же вам 
необходимо определить макрофункцию, делайте это с осторожностью. Макрофунк- 
ция — это простая текстовая подстановка. Параметры в ее объявлении заменяются 
фактическими аргументами, и полученный фрагмент вставляется в виде текста на 
место вызова макроса. Это очень существенное отличие от функций, которое может 
вызвать ряд проблем. Возьмем, например, следующее выражение: 


1 / зацакге (х) 
Здесь все в порядке, если запахе (х) — обычная функция. Но пусть это будет 
макрос, определенный следующим образом: 


? #аеЁ1пе зачакге (х) (х) * (х) 


В Этом случае макроподстановка даст следующее ошибочное выражение: 
? 1/ (х) * (х) 


Чтобы исправить ошибку, макрос следует переписать таким образом: 


#аеЕ1пе зачаге (х) ((х) * (х)) 


Все эти скобки совершенно необходимы. Но даже корректное заключение в скоб- 
ки все равно не решает проблему многократного вычисления аргументов. Если опе- 
рация достаточно громоздка или настолько часто встречается, что ее можно сделать 
стандартным средством, лучше оформите ее как функцию. 

В языке С++ аппарат встраиваемых функций позволяет избежать всех этих оши- 
бок и при этом сохраняет все преимущества быстродействия, присущие макрофунк- 
циям. Он вполне подходит для определения небольших функций, вычисляющих или 
устанавливающих какое-нибудь одно значение. 


Упражнение 1.9. Какие ошибки или проблемы могут возникнуть при использо- 
вании этой макрофункции? 


? #аеЁ1пе ІЅРІСІТ (с) ((с >= '0') && (с <= '9'!)) ?1:0 
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1.5. Явные числовые константы 


В программах часто встречаются записанные в явном виде числовые константы, 
для обозначения которых существует термин “магические числа” (таёс питђетз). 
Это могут быть просто числа в выражениях, размеры массивов, позиции символов, 
коэффициенты преобразований и т.п. 


Присваивайте константам символические имена. Любое число, отличное от 0 
или 1, вполне может подпадать под приведенное выше определение, поэтому жела- 
тельно, чтобы оно имело свое имя. Само по себе число в исходном коде не дает ника- 
ких указаний о его происхождении, смысле или степени важности, из-за чего про- 
грамму становится труднее читать и дорабатывать. Например, следующий отрывок 
из программы построения гистограмм на текстовом терминале размером 24 строки 
на 80 столбцов слишком перегружен явными константами и поэтому труден для 
понимания: 


? Ғас = Ш / 20; /* выбор масштабного коэффициента */ 
? 1Е (Рас < 1) 

? Гас = 1; 

? /* генерирование гистограммы */ 
? Бог (і = 0, сої - 0; і < 27; 1++, ј++) 

? со1 += 3; 

? К = 21 - (1её [1] / Еас); 

? знак =. Че] == 0) и се 

? Бог (] = К; ј < 22; ј++) 

? агам (3, со1, ѕіёаг); 

> 

? агам (23, 2, ' !); /* метка оси х */ 

? Бог (і = 'А!; і <= '2'; 1++) 

? ргіпеЁ ("%с ", і); 


Среди прочих данных этот код содержит такие константы, как 20, 21, 22, 23 и 27. 
Они явно имеют отношение друг к другу... или нет? Фактически в основе работы 
этой программы лежат всего лишь три важнейшие константы: 24 (количество строк 
на экране), 80 (количество столбцов на экране) и 26 (количество букв в алфавите). 
Но ни одна из этих констант в явном виде не присутствует в коде, из-за чего стано- 
вится непонятно, откуда взялись остальные. 

Присваивая основным числовым константам символические имена, код можно 
сделать намного понятнее. Сразу обнаруживается, что константа 3 возникла в 
результате операции (80-1) /26, а массив Іес должен содержать 26 элементов, 
а не 27 (лишний элемент появляется оттого, что координаты на экране нумеруются 
начиная с единицы, а не с нуля). Сделаем еще пару упрощений и получим следую- 
щий результат: 


епот { 
МІМВОИ = 1, /* верхний край */ 
МІМСО = 1, /* левый край */ 
МАХКОИ = 24, /* нижний край (<=) */ 
МАХСОШ = 80, /* правый край (<=) */ 
АВЕІВОИ = 1, /* местоположение меток */ 
МЕТ = 26, /* длина алфавита */ 


НЕТСНТ = МАХВОИ - 4, /* высота столбцов гистограммы 
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ый 
х / 


МІР”ТН = (МАХСОІ-1) /МЕТ /* ширина столбцов гистограммы 


Гас = (1іт + НЕТСНТ-1) / НЕТСНТ; /* выбор масштабного 
коэффициента */ 
1Е (Ғас < 1); 


ас: =^51= 
Бог (і = 0; 1 < МЕТ; 1++) { /* генерирование гистограммы 
*/ 
1Е (1еб[і] == 0) 
сопёіпче; 


Ғог (3) = НЕІСНТ - 1её [1] /Рас; ) < НЕТСНТ; ј++) 
агам (3+1 + АВЕІВОМ, (1+1)*МТОТН, '*!); 


агам (МАХВОЙ-1, МІМСОІ+1, ' '!); /* метка оси х */ 
Рог (і = 'А'; і <= '7'; 1++) 
ЮріпЕс ("Зе "т, 2) 


Вот теперь уже гораздо понятнее, что же делается в основном цикле. Он пред- 
ставляет собой стандартную конструкцию с перебором от 0 до МІЕТ, т.е. по всем 
имеющимся элементам данных. Вызовы функции агам также стали более вразуми- 
тельными, потому что слова МАХКОЙ и МТМСОГ напоминают о смысле и порядке 
следования аргументов. Что еще более важно, теперь эту программу легче адаптиро- 
вать к новому размеру экрана или данным другого типа. Числовые константы утра- 
тили загадочность, а заодно и вся программа стала более понятной. 


Определяйте числа как переменные-константы, а не как макросы. Програм- 
мисты на языке С традиционно определяют символические константы с помощью 
директивы #4еЁ1пе. Препроцессор С — это мощный, но неповоротливый инстру- 
мент, а макроопределения несут с собой большую опасность, потому что они изме- 
няют лексическую структуру исходного кода программы. Поэтому желательно дей- 
ствовать стандартными средствами самого языка. В языках С и С++ целочисленные 
константы можно определить как элементы перечислимого типа в операторе епим, 
как это было сделано в предыдущем примере. В языке С++ константы любого типа 
можно определить с помощью ключевого слова сопзі: 


сопзЕ іп МАХКОИ = 24, МАХСОГ = 80; 


В языке Јауа для этого служит ключевое слово Ғіпа1: 


ѕсасіс Ё1па1 іп МАХВОМ = 24, МАХСОІ = 80; 


В языке С тоже есть ключевое слово сопзе, но такие константы не могут слу- 
жить границами массивов, поэтому в С следует отдавать предпочтение перечисли- 
мому типу (епот). 


Используйте символьные константы, а не их числовые коды. Для анализа 
свойств символьных переменных следует пользоваться функциями из заголовочного 
файла <сеуре .Һ»> или их эквивалентами. Возьмем, например, следующую проверку: 


? 1Е (с >= 65 && с <= 90) 
А 
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Ее правильность целиком и полностью зависит от конкретной кодировки, 
Т.е. КОДОВОГО символьного набора. Лучше записать это следующим образом: 


Э. ЇЁ (с >= 'А' && с <= '21!) 
? 


Но и эта конструкция может не дать желаемого эффекта, если буквы в наборе 
идут не подряд или же алфавит включает и другие символы. В языке С или С++ 
лучше всего воспользоваться библиотечной функцией: 


1Е (іѕиррег (с)) 


В ]ауа эта же проверка оформляется таким образом: 


1Е (Сһагасбег.іѕОррегСаѕе (с)) 


Нечто подобное происходит с числом 0, которое может фигурировать в програм- 
мах в самых разных контекстах. Конечно, компилятор всегда приведет его к нужно- 
му типу самостоятельно, однако при чтении программы полезно понимать, какую 
роль играет нуль в том или ином случае. Например, в С для обозначения нулевого 
указателя следует пользоваться выражениями (уоіа *)0 или МОШ,, а для пред- 
ставления нулевого байта в конце строки — выражением '\0'. Другими словами, 
не следует писать так: 


? ЗЕИ- =" 105 
? папе [1] = 0; 
? 20 


Лучше записать это таким образом: 


зе’ = М; 
пате [1] = '\0'; 
= 0.0: 


Здесь всякий раз используется соответствующая ситуации константа с явно вы- 
раженным типом, а символ 0 обозначает только целое число “нуль”. Если писать 
именно так, то в каждом случае будет ясно предназначение константы и программа 
приобретет черты самодокументированности. Правда, в С++ нулевой указатель по- 
всеместно обозначается просто 0, а не МО. В языке ]ауа этот вопрос решен лучше 
всего — введением ключевого слова па11, обозначающим пустую (ни на что не ука- 
зывающую) объектную ссылку. 


Вычисляйте размер объекта стандартными средствами языка. Не обозна- 
чайте размеры объектов данных явными константами — т.е. например, пишите 
312еоЕ (116) вместо 2 или 4. Аналогично, лучше записать 312еоЕ (аггау [0]), 
чем $12еоЕ (118), потому что если тип массива изменится, это позволит сэконо- 
мить одно исправление. 
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Операция 512еоЕ часто избавляет от необходимости изобретать лишние имена 
для констант, которые обозначают размеры массивов. Рассмотрим, например, такую 
запись: 


сһаг БиЁ [1024]; 
ЕчеЕз (БаЁ, в12еоЕ (БаЁ), ѕёаіп); 


Размер буфера — явная литеральная константа, но, к счастью, она встречается в 
программе всего один раз, а именно в объявлении массива. Нет никакого смысла 
изобретать символическое имя для размера локального массива, но вот написать код 
так, чтобы в нем не пришлось ничего менять при изменении размера массива, опре- 
деленно имеет смысл. 

В объектах-массивах Јауа имеется поле 1епчеЕН, которое содержит количество 
элементов: 


сһаг Ыри [] пем сһаг [1024]; 


Ғор (116 і 0; 1 < ри#.1епаёһ; і++) 


В языках Си С++ нет эквивалента поля .1епаєһ, но если объявление массива 


доступно в данном блоке программы, то его размер можно вычислить с помощью 
следующего макроса: 


#дӢеҒіпе МЕГЕМЅ (аггау) (ѕілеої (аггау) / в12еоЕ (аггау[0])) 
аӢоцр1е ари [100]; 


Ғор (і = 0; і < МЕБЕМ$ (араЕ); 1++) 


Размер массива задается только в одном месте; если впоследствии он изменяется, 
то код не приходится исправлять. В данном случае проблема многократного вычис- 
ления аргумента не имеет места, поскольку выполняемые операции не сопровожда- 
ются побочными эффектами. Более того, вычисления фактически выполняются на 
этапе компиляции. Вот это как раз подходящий случай для использования макроса, 
потому что именно макрос может сделать то, чего не может функция: вычислить 
размер массива по его объявлению. 


Упражнение 1.10. Как бы вы переписали данные определения, чтобы минимизи- 
ровать потенциальную возможность ошибки? 


? #аеҒіпе ЕТ2МЕТЕВ 0.3048 

? #аеҒіпе МЕТЕВ2ЕТ 3.28084 
? #аеҒіпе МІ2ЕТ 5280.0 

Э #аеҒіпе МІ2КМ 1.609344 
? 


#аеғіпе 50М1250М 2.589988 
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1.6. Комментарии 


Комментарии предназначены для того, чтобы программу было легче читать и по- 
нимать. Но от них мало толку, если они попросту дублируют то, что и так ясно из 
текста программы, противоречат содержанию кода или отвлекают читателя про- 
странными, красиво оформленными описаниями. Лучшие комментарии — это те, 
которые помогают лучше понять код, давая либо краткое описание самых сущест- 
венных деталей, либо расширенное представление о выполняемых операциях. 


Не повторяйте очевидное. В комментариях не должна повторяться информа- 
ция, очевидная из самого текста программы, например, тот факт, что операция 1++ 
инкрементирует счетчик 1. Вот некоторые из наших любимых образчиков бесполез- 
ных комментариев: 


? /* 

? * Блок АаеЁац1е 

? * / 

? аеЁац1 6: 

? ргеак; 

? /* возвращается значение 50ССЕЅ5 */ 

? геёцгп $50ССЕ55; 

Е. регосоцпе++; /* Инкрементирование счетчика нулевой позиции */ 


/* Инициализация поля "6офа1" полем "питрегр гесеіуеа" */ 
поде->6о$а1 = поде->попрег гесеіуеа; 


Такие комментарии нужно удалять из исходного текста; они просто загроможда- 
ют программу. 

Комментарии должны прояснять что-то такое, что не до конца понятно из самого 
кода, или же сводить воедино информацию, разбросанную по разным местам про- 
граммы. Если выполняется некая тонкая операция, комментарий может оказаться 
необходимым для ее понимания, но если все и так ясно из операторов, то пересказ 
того же самого своими словами лишен смысла: 


? мһі1е ((с = дебсвах()) != ЕОЕ && 15врасе(с)) 

? а /* пропуск пробелов */ 
? ЇЁ (с == ЕОЕ) /* конец файла */ 

? суре = епаоЕЕ11е; 

? е1зе ЇЕ (с == '(') /* левая скобка */ 

? Суре = ІеЁбрагеп; 

? е1зе 1Е (с == !)!) /* правая скобка */ 

? суре = гідһірагеп; 

? е1ѕе ЇЁ (с == !;!) /* точка с запятой */ 
? Суре = ѕетісо1оп; 

? е1ѕе 1Е (іѕ ор(с)) /* знак операции */ 

? Суре = орегаіоү; 

? е1ѕе 1Е (15491916 (с)) /* число */ 

> 
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Эти комментарии тоже следует убрать из программы, поскольку в ней уже опре- 
делены достаточно информативные символические константы. 


Комментируйте функции и глобальные данные. Конечно, комментарии могут 
быть и полезными. Например, следует комментировать функции, глобальные пере- 
менные, определения констант, поля структур и классов и любые места, где резюме 
может прояснить смысл кода. 

Глобальные переменные имеют тенденцию “выскакивать” то тут, то там в разных 
местах программы; комментарий к ним служит напоминанием, откуда они взялись. 
Вот пример из программы к главе 3 этой книги: 


ЗЕКиСЕ Ѕбабе { /* список префиксов и суффиксов */ 


сһаг *ргеЕ [МРВЕЕ]; /* слова-префиксы */ 
ЗаЕЁЕ1х *31Е; /* список суффиксов */ 
ЗЕабе *пехі; /* следующий элемент в хэш-таблице */ 


' 


Комментарий перед определением функции служит удачным введением к чте- 
нию самого кода функции. Если функция не слишком длинная и технически не- 
сложная, то достаточно одной строки: 


// хапаотм: возвращает целое число из диапазона [0..х-1] 
іп гапаом (116 к) 


геіцгп (1п6) (Маһ. #1оогү (Маһ. гапот () *х)); 


Иногда код бывает очень сложным; в частности, таковым может быть реализуе- 
мый алгоритм или используемая структура данных. В этом случае читателю может 
помочь ссылка на первоисточник. Может оказаться ценной также информация о 
том, почему были выбраны те или иные технические решения. Следующий коммен- 
тарий предваряет исключительно эффективную реализацию обратного дискретного 
косинус-преобразования (ДКП), используемую в декодере ЈРЕС-изображений: 


/* 

х јас: масштабированная целочисленная реализация обратного 

* двумерного дискретного косинус-преобразования с ячейкой 8х8, 
* по алгоритму Чен-Вана (ТЕЕЕ АЅ5Рр-32, с.803-816, август 1984) 
ж 

* 32-разрядная целочисленная арифметика (8-разрядные коэффициенты) 
* 11 множителей, 29 добавок на одно ДКП 

ж 

* Коэффициенты расширены до 12 бит для совместимости 

* со стандартом ТЕЕЕ 1180-1990 

ж 


/ 


ѕіасіс уоіа іасіё (116 Ы[8*8]) 


} 


В этом полезном комментарии дана ссылка на источник, кратко описаны исполь- 
зуемые данные, указаны сведения о производительности алгоритма, а также отмече- 
но, каки зачем этот алгоритм модифицирован по сравнению с исходным. 
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Не комментируйте плохой код — переписывайте его. Конечно, следует ком- 
ментировать все необычные или запутанные места. Но если объем комментариев 
начинает намного превышать объем кода, то, возможно, сам код требует серьезной 
доработки. В следующем примере для объяснения одного оператора понадобился 
длинный маловразумительный комментарий, да еще и отладочная директива услов- 
ной компиляции: 


? /* Если "геза16" равен 0, есть соответствие, возвращаем ёүце (не нуль). 


? В противном случае "кеза1е" не нуль, возвращаем Ёа1зе (нуль). */ 
> 

? #1ЕаеЕ РЕВОС 

2 ру1пЕЕ("*** 15змога кебагпз !геза1Е = %А\п", ! геѕи1б); 

? ЕЕ азр (з6аоц®); 

? #епаіғ 

2 

? 


геёигп (! геѕи1ё); 


Отрицания трудно воспринимаются, поэтому их следует избегать. Малоинформа- 
тивное имя переменной геѕо1+ тоже создает проблемы в понимании текста. Если дать 
ей описательное имя тассһҒоџпа (“найдено соответствие”), комментарий становится 
вообще ненужным и оператор вывода тоже приобретает более аккуратный вид: 

#1ЕаеЕ ОЕВОС 
ргіпіЁ ("*** 1змога гебагпз таёсһҒоцпа = %А\п", тмабсВЁЕоцпа); 


ЕЕ] азВ (ѕіаоцё) ; 
#епа1Е 


геёигп паёсһЁоцпа; 


Не противоречьте коду. Большинство комментариев соответствует коду в 
момент его написания, но по мере исправления ошибок и доработки программы 
содержание комментариев может все больше отклоняться от исходного текста, если 
их не обновлять. Это вполне вероятное объяснение для того расхождения между 
кодом и комментарием, которое было приведено в начале этой главы. 

В чем бы ни состояла причина расхождения, комментарий, который не соответст- 
вует коду, порождает недоразумения. Бывает, что программисты проводят многие 
бесполезные часы за отладкой кода только потому, что приняли ошибочный ком- 
ментарий за чистую монету. Внося изменения в код, не забывайте делать это и с 
комментариями. | 

Комментарии должны не только согласовываться с кодом, но и обеспечивать его 
поддержку. В следующем примере комментарий составлен корректно (он объясняет 
назначение двух последующих строк), но противоречит фактическому содержанию 
кода, потому что в комментарии речь идет о символах конца строки, а в коде — 
о символах пустого пространства: 


? С1те (&пом) ; 

? зЕхсру (Чавке, се1те (&пом)) ; 

? /* убираем символ конца строки, скопированный из сііте */ 
? і = 0; 

? мһі1е (аабе [1] >= ' ') 1++; 

? 


Часе [1] = 0; 
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Одно из напрашивающихся усовершенствований — это переписать код в более 
стандартной форме: 


? С1те (&пом); 

? ѕігсру (Чабе, сбіте (&пом))}; 

? /* убираем символ конца строки, скопированный из сбіте */ 
? Ғор (і = 0; абе [1] != '\п'; 1++) 

2, } 

? аабе [1] = '\0'; 


Теперь код и комментарий согласуются между собой, но их можно еще усовер- 
шенствовать, сделав более прямыми. Задача СОСТОИТ В ТОМ, чтобы удалить символ 
конца строки, который функция сЕ1те помещает в последнюю позицию возвра- 
щаемой ею строки. Комментарий должен утверждать именно это, и то же самое 
ДОЛЖНО быть ясно из исходного кода: 

Сіте (&пом) ; 
ѕегсру (аабе, сЕ1те (&пом)) ; 


/* сбіме добавляет символ конца строки; убираем его */ 
Яаке [56 х1еп (дасе) -1] = '\0'; 


Последний оператор представляет собой идиоматическую конструкцию языка С 
для удаления последнего символа из строки. Теперь код стал коротким, стандарт- 
ным, хорошо понятным, а комментарий обеспечивает необходимую информацион- 
ную поддержку в виде объяснения, зачем нужна эта операция. 


Проясняйте, а не запутывайте. Предполагается, что комментарии должны 
делать трудные места программы более понятными, а не создавать дополнительные 
препятствия для понимания. Следующий пример соответствует нашим рекоменда- 
циям по комментированию функций и объяснению их необычных возможностей. 
С другой стороны, рассматривается функция зЕгспр, и ее необычные возможности 
играют второстепенную роль по сравнению с основной задачей — реализацией стан- 
дартного, хорошо известного интерфейса. 


1Е(*$1>*52) гебцагп (1); 
гебакп (-1); 


? 106 ѕегстр (сһаг *51, сһаг *52) 

2 /* функция сравнения строк; возвращает -1, если строка $1 */ 
Э /* старше 52 в алфавитном порядке; 0, если строки равны; */ 
? /* и 1, если $1 младше $2 */ 

> 

? мһі1е (*51==*52) { 

? ЇЁ (*51=='\0') гебигп(0); 

? 51++; 

? 52++; 

? 

? 

? 

? 


} 


Если для объяснения операции требуется больше чем несколько слов, это часто 
указывает на необходимость усовершенствовать код. В нашем случае код, может 
быть, и можно усовершенствовать, но главная проблема заключается не в нем, а в 
комментарии. Комментарий имеет почти такую же длину, как и реализация функ- 
ции; кроме того, он еще и не вполне понятен (например, что такое “старше”?). 
Подведем итог. Код функции довольно труден для понимания, но это реализация 
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стандартной операции, поэтому комментарий должен носить такой характер: давать 
резюме выполняемых действий и ссылаться на источник, в котором определена дан- 
ная операция. Вот все, что для этого нужно: 

/* зЕгстр: возвращает < 0, если 51<52, > 0, если 51>52, 0, если 
равны */ 


/* АМЅІ С, раздел 4.11.4.2 */ 
106 з6гстр(сопз® сһаг *51, сопѕё сһаг *52) 


{ 
} 


Студентов учат, что необходимо комментировать все подряд. От профессиональ- 
ных программистов часто требуют, чтобы они комментировали весь свой код. Но сам 
смысл комментирования можно легко потерять, слепо следуя предписаниям. Коммен- 
тарии предназначены для того, чтобы читатель легко понял те части программы, смысл 
которых не ясен из самого кода. Старайтесь по возможности писать код, легкий для 
понимания. Чем лучше это получается, тем меньше требуется комментариев. Хороший 
код обычно требует меньшего объема комментариев, чем плохой. 


Упражнение 1.11. Выскажите свое мнение об этих комментариях. 


о 


чоій Я1сЕ: :іпѕегі (ве х1па& м) 
// возвращает 1, если м есть в словаре, 0 в противном случае 


о 


? 1Е (п > МАХ || п$% 2 > 0) // проверка на четность 


// Запись сообщения 
// Приращение счетчика строк после каждой записанной строки 


уоіа мгіёе меззаче () 


// приращение счетчика строк 

11пе_питрег = 1іпе питрег + 1; 

Ғргіпё# (Ғооцё, "#4 %5\п%а %5\п%а %5\п", 
1іпе потрег, НЕАРЕВ, 
1іпе потрег + 1, ВОрҮ, 
Ііпе потрег + 2, ТКАІЕВ); 

// приращение счетчика строк 

1іпе побег = 1іпе питрег + 2; 


0 00 10 0) 0) 0) 0) 000) 0 0 0 0 
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В этой главе мы рассмотрели некоторые основные вопросы стиля программиро- 
вания: информативные имена объектов, понятную запись выражений, стандартные 
управляющие конструкции, удобочитаемость кода и комментариев к нему, важность 
соблюдения единой, последовательной системы соглашений и идиоматических 
конструкций для решения всех перечисленных задач. Трудно спорить с тем, что все 
это благотворно сказывается на коде. 
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Но зачем вообще беспокоиться о стиле? Кому какое дело, как выглядит исходный 
код программы, если она работает? Не слишком ли много времени нужно тратить на 
придание коду должного внешнего вида? Разве правила стиля в конце концов не 
являются надуманными? 

Ответ состоит в том, что хорошо написанный код легко читать и понимать, он 
почти наверняка содержит меньше ошибок, а также очень часто еще и короче кода, 
небрежно собранного в кучу и не приведенного к хорошему стилю. В стремлении 
сдать работоспособную программу к заданному сроку бывает очень легко пожертво- 
вать требованиями стиля, чтобы позаботиться о нем позже. Но эта жертва может 
дорого обойтись. Некоторые из примеров этой главы показывают, что может 
случиться, если не уделить достаточно внимания хорошему стилю программиро- 
вания. Небрежный код — это плохой код. Он не просто неуклюже написан и 
трудночитаем, он чаще всего содержит серьезные ошибки. 

Ключевой вывод состоит в том, что хороший стиль программирования нужно 
сделать своей второй натурой. Если постоянно думать о стиле при написании кода, а 
также время от времени пересматривать и улучшать его, то у вас со временем появится 
новая хорошая привычка. Как только у вас выработается необходимый автоматизм, 
требования стиля будут удовлетворяться подсознательно, и даже программы, 
написанные в предельно сжатые сроки, приобретут более высокое качество. 


Дополнительная литература 


Как говорилось в начале главы, написание хорошего кода имеет много общего с 
написанием хорошего литературного текста. Лучшей из небольших книг по стили- 
стике английского языка по праву считается книга №. Ѕгипк, Е.В. \!Бце, 
Тһе Еіетепіѕ оў 5 ще (АПуп & Васоп). 

В этой главе излагается подход к стилю, принятый в книге В.Кегпіғћап, 
Р.]. РІацвег, Тре Еетет оў Рғортаттіпр Зе (МсСта\-НШ, 1978). Превосходные 
рекомендации по стилю программирования можно найти в книге Ѕѓеуе Марие, 
Упипа 5ойа Со4е (МсгозоЁ Ргезз, 1993). Полезные дискуссии по стилю имеются 
также в книгах Зцеуе МсСоппе!, Сойе Сотрее (Місгоѕоіє Ргезз, 1993) и Реѓег уап 
деп Г4п4еп, Ехрет С Рғортаттіпр: Пеер С Ѕестіѕ (Ргеписе На]і, 1994). 


Алгоритмы и структуры 
данных 


В конечном счете, только знакомство с методами и средствами, применяе- 
мыми на практике, может помочь найти правильное решение для постав- 
ленной задачи, и только наличие определенного опыта позволит неизменно 
достигать профессиональных результатов. 


> 


Рэймонд Филдинг. “Техника съемки спецэффектов? 
(Каутопа Не тв, Тће Тесһпідие о Зреса| ЕЌесёѕ СтетабоэтарВу) 


Изучение алгоритмов и структур данных составляет фундамент науки информа- 
тики и программирования; это огромная область знаний, изобилующая элегантными 
методами и тонкими математическими доказательствами. Теорию алгоритмов и 
структур данных не следует воспринимать как игрушку для ученых-теоретиков. 
Хороший алгоритм или структура делает возможным секундное решение задачи, 
на которую могли бы уйти годы работы. 

В таких специализированных областях, как графика, управление базами данных, 
синтаксический анализ, численные методы, моделирование, способность решать 
задачи почти целиком зависит от знания разработанных в этой области алгоритмов и 
структур данных. Если вы пишете программу из области, новой для вас, то вы про- 
сто обязаны выяснить, что уже наработано другими людьми в этой области. Иначе 
можно потратить время зря, делая плохо то, что другие давно сделали хорошо. 

Алгоритмы и структуры данных используются в каждой программе, но лишь в 
очень немногих программах приходится изобретать что-то действительно новое. 
Даже в таких сложных программах, как компиляторы и М№еЬ-браузеры, структуры 
данных представляют собой большей частью массивы, списки, деревья и хэш- 
таблицы. Если потребуются какие-то более сложные объекты, то почти наверняка 
они будут основаны на перечисленных простых конструкциях. Соответственно, для 
большинства программистов задача заключается в том, чтобы узнать, какие алго- 
ритмы и структуры данных существуют для решения задач определенного типа, 
и правильно выбрать нужные из их числа. 

Имеется всего лишь несколько фундаментальных алгоритмов, встречающихся 
почти во всех программах (в основном это алгоритмы поиска и сортировки), причем 
они нередко включены в состав библиотек. Аналогично, почти все структуры дан- 
ных являются производными от нескольких базовых типов. Поэтому материал, 
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рассматриваемый в этой главе, знаком практически всем программистам. Мы напи- 
сали рабочие версии кода для того, чтобы иметь конкретный материал для обсужде- 
ния, и читатель может использовать соответствующие фрагменты кода практически 
дословно. Однако желательно делать это только после тщательного изучения ассор- 
тимента средств, предлагаемого тем или иным языком и его библиотеками. 


2.1. Поиск 


Если говорить о хранении статических табличных данных, то ничто не может 
сравниться по эффективности с массивом. Инициализация на этапе компиляции 
позволяет конструировать массивы самыми простыми средствами и без больших 
затрат ресурсов. (В языке Јауа инициализация происходит на этапе выполнения 
программы, но эти подробности реализации несущественны, если массив не слиш- 
ком велик.) Пусть, например, мы пишем программу, подсчитывающую в тексте 
“слова-паразиты”. Такие слова обычно встречаются слишком часто в плохо написан- 
ном тексте. 


сһаг *#1ар[] = { 
"асЕца11у", 
"јові ША 
"аџібе" л 
"уеа11у", 
мо 


7 


Подпрограмма поиска должна знать, сколько элементов содержится в массиве. 
Один из способов дать ей это понять заключается в том, чтобы передать длину в 
качестве аргумента, а другой способ (используемый здесь) состоит в том, чтобы по- 
местить маркер МОТ: в конец массива: 


/* 1оокир: последовательный поиск слова в массиве */ 
106 1Іоокир (сһаг *мога, сһаг *аггау []) 


{ 
іп і; 
Ғог (1 = 0; аүүгау [1] != МОШ; і++) 
1Е (ѕзігстр (мога, аггау[1]) == 0) 
хебогп і; 
геіцџгп -1; 


} 


В языках С и С++ параметр, представляющий собой массив строк, можно объя- 
вить как сһаг *аггау [] или сһаг **аггәау. Хотя эти формы эквивалентны, пер- 
вый способ яснее указывает на способ использования объекта данных. 

Данный алгоритм поиска называется последовательным поиском, потому что в 
нем перебираются все элементы подряд, пока не будет найден нужный. Если объем 
данных сравнительно невелик, последовательный поиск работает достаточно быст- 
ро. Существуют стандартные библиотечные функции для выполнения последова- 
тельного поиска в совокупностях данных различных типов. Например, такие функ- 
ции, как ѕёгсһг и зетзет, разыскивают первое вхождение соответственно символа 
и подстроки в строке С/С++; класс ЗЕ х1па языка Јауа содержит метод 1паехоЕ 
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для той же цели; нетипизированные алгоритмы Ғіпа языка С++ применимы к 
большинству типов данных. Если для типа данных, с которым вы работаете, уже есть 
стандартная функция, воспользуйтесь ею. 

Последовательный поиск легко реализуется, но объем выполняемых в нем опера- 
ций прямо пропорционален объему имеющихся данных. Удвоение количества элемен- 
тов в массиве приведет к удвоению времени на поиск элемента, особенно если его нет 
среди данных. Это линейная зависимость, т.е. время поиска является линейной функ- 
цией объема данных; вот почему этот метод еще называется линейным поиском. 

Ниже приведен фрагмент массива более реалистичного размера, взятый из про- 
граммы синтаксического анализа языка НТМГ. В этом массиве определяются сим- 
волические имена для более чем ста текстовых символов: 

суреаеЕ зѕігисё Машеуа1 Машеуа1; 
ЗЕКисЕ Матеуа1 { 


сһаг *паме; 

ре уа1ае; 
/* Символы НТМ; например, Ае113 обозначает лигатуру А и Е. */ 
/* Значения соответствуют кодировке Шпісоде/15010646. */ 
Мамеуа1 Һёт1сҺагѕ [] = 


"АЕ11а", 0%00с6, 
"АДасоёе", 0х00с1, 
"Асігс", 0х00с2, 
ж. ж/ 


"теба", 0х03Ы6, 


}; 


Для таких больших массивов, как этот, удобнее выполнять поиск делением попо- 
лам (дихотомией), или двоичный поиск. Алгоритм двоичного поиска — это математи- 
ческая формализация того способа, которым мы, люди, разыскиваем слово в словаре. 
Сначала берем средний элемент. Если он больше того, который мы ищем, переходим 
к поиску в первой половине массива; в противном случае ищем во второй половине. 
Повторяем процедуру до тех пор, пока не найдем нужный элемент или не удостове- 
римся, что его нет среди имеющихся данных. 

Для выполнения двоичного поиска таблица данных должна быть отсортирована. 
В данном случае это так; да и вообще, данные полезно сортировать — это и признак 
хорошего стиля, и помощь в поиске нужной информации. Кроме того, необходимо 
знать длину таблицы. В этом может помочь макрос МЕЪЕМ$Б, приведенный в главе 1: 


ргіпёЁ ("Тһе НТМЬ ёар1е Ваз %а могаз\п", МЕБЕМ$ (рет1сраг8)); 


Функция двоичного поиска в этой таблице может выглядеть, например, таким 
образом: 


/* 1оокир: двоичный поиск строки пате в массиве ёар; возвращает 
индекс */ 
106 1Іоокир (сһаг *паше, Матеуа1 ёар [], 1пЕ пёар) 


{ 


іп 1ом, һҺієһ, піа, сюр; 


Том = 0; 
Һідһ = піар - 1; 
ућі1е (1ом <= Һідһ) { 
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01а = (1ом + 6191) / 2; 
спр = зЕкспр (пате, бар [тіа] .пате) ; 
1Е (стр < 0) 
Һі9һ = піа - 1; 
е1зе 1Е (стр > 0) 
1ом = піа + 1; 
е1зе /* элемент найден */ 
гебагп тій; 


} 


геёџүп -1; /* элемент не найден */ 


} 


Подведем итог. Чтобы найти в массиве ВЕп1сВахз индекс символа $ (“одна 
вторая”), необходимо записать такой оператор: 


Һа1# = 1оокир ("Ехас12", БЕш1сВахз, МЕШЕМ$ (ВЕш1срВатз)); 


В ходе двоичного поиска на каждом шаге отбрасывается половина оставшихся 
данных. Таким образом, процедура включает столько шагов, сколько раз можно по- 
делить количество элементов на 2, пока не останется один элемент. Это равно 109, п, 
не считая ошибки округления. Если, например, массив содержит 1000 элементов, то 
линейный поиск может занять до 1000 шагов, тогда как двоичный — около 10. В мас- 
сиве из миллиона элементов линейный поиск требует порядка миллиона операций 
сравнения, а двоичный — порядка 20. Чем больше в массиве элементов, тем большее 
преимущество имеет алгоритм двоичного поиска над линейным. Начиная с некото- 
рого объема исходных данных (зависящего от конкретной реализации), двоичный 
поиск всегда работает быстрее, чем линейный. 


2.2. Сортировка 


Алгоритм двоичного поиска работает только в том случае, если элементы массива 
отсортированы. Если в некотором наборе данных предстоит часто выполнять поиск, 
то имеет смысл отсортировать его один раз, а затем использовать процедуру двоич- 
ного поиска для нахождения нужных элементов. Если набор данных известен зара- 
нее, его можно отсортировать на этапе написания программы и окончательно сфор- 
мировать при компиляции. Если же это не так, то его придется сортировать на этапе 
выполнения программы. 

Одним из лучших универсальных методов сортировки является алгоритм быст- 
рой сортировки (дисЁ5от®), изобретенный в 1960 году Ч.Э.Р. Хоаром (С.А.В. Ноаге). 
Этот алгоритм — превосходная демонстрация того, как можно обойтись без лишних 
вычислений. Для его реализации массив делится на “большие” и “малые” элементы: 


выбирается один элемент в массиве (назовем его опорным элементом — ріооё); 
все остальные элементы делятся на две группы: 

“малые”, т.е. меньшие, чем опорный; 

“большие”, т.е. превосходящие по значению опорный или равные ему; 
каждая из групп подвергается рекурсивной сортировке. 
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По окончании этого процесса массив оказывается упорядоченным. Этот алгоритм 
работает очень быстро, поскольку если известно, что какой-либо элемент меньше 
опорного, то уже нет нужды сравнивать его со всеми “большими” элементами. Ана- 
логично, “большие” элементы не сравниваются с “малыми”. Поэтому данный алго- 
ритм значительно быстрее, чем более простые наподобие сортировки простыми 
вставками или методом пузырьков, в которых каждый элемент непосредственно 
сравнивается со всеми остальными. 

Алгоритм быстрой сортировки весьма практичен и эффективен; проведено множе- 
ство исследований его свойств и разработано огромное количество его вариантов. Вер- 
сия, которую мы приводим здесь, — одна из простейших, но далеко не самых быстрых. 

Приведенная ниже функция аціскзогі+ сортирует массив целых чисел. 


/* аоіскѕогё: сортирует у[0]...у[а-1] в порядке возрастания */ 
уоіа аиіскзогі (іпі у[], іпё п) 


іпі і, 1аѕё; 


ТЕ (п <= 1) /* ничего не нужно делать */ 
гесиагп; 
ѕзмар (у, 0, хапа() % п); /* переместить опору в у[0] */ 
1аѕё = 0; 
Ғог (і = 1; 1 < п; 1++) /* разбиение */ 


ТЕ (у[1] < у[0]) 
ѕмар (у, ++1аѕі, 1); 


ѕмар (у, 0, 1аѕё); /* восстановить опору */ 
аџісквогі (у, 1аѕі); /* рекурсивная сортировка */ 
аоіскѕогё (у+1аѕё+1, п-1аѕё-1); /* каждой из частей */ 


Операция змар, меняющая местами два элемента, фигурирует в функции 
ачіскзогі три раза, поэтому ее лучше всего оформить в виде отдельной функции: 


/* змар: меняет местами элементы у[і] и у[5] */ 
уоіа змар (іп у[], 106 і, іпё 3) 


106 ёетр; 


сетр у [1]; 
у [1] у[5]1; 
у[51 = у[і]; 


При разбиении массива в нем случайным образом выбирается опорный элемент; 
затем он временно перебрасывается в начало массива; выполняется перебор осталь- 
ных элементов, причем “малые” (меньшие, чем опорный) перемещаются в начало 
(в позицию 1азѕё), а “большие” — в конец (в позицию 1). В начале этой процедуры, 
сразу после перемещения опорного элемента в начало, имеет место равенство 
Іаѕі = 0,а элементы оті = 1 доп-1 еще не проанализированы: 


р Еще не проанализированы 


Іаѕё 1 п-1 
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Что касается перебора в цикле Еот, то элементы от 1 до 1азі строго меньше, чем 
опорный, элементы от 1аѕі+1 до 1-1 больше или равны опорному, а элементы от 
1 до п-1 еще не проанализированы. До тех пор, пока не начнет выполняться соот- 
ношение у [і] >= у[0], элемент у [1] может участвовать в обмене с самим собой; 
из-за этого тратится некоторое время, но не так уж много, чтобы об этом беспокоиться. 


р <р 2р осад 
р ! } і 
0 1 Іаѕі 1 п-1 


После разбиения всех элементов на группы элемент 0 меняется местами с элемен- 
том 1азё, чтобы поместить опорный элемент в его окончательную позицию. Это по- 
зволяет сохранить правильный порядок. Теперь массив выглядит следующим образом: 


<р р >= р 
\ | 
0 Іаѕі п-1 


Эта же процедура применяется к левому и правому подмассивам; как только она 
закончена, массив оказывается упорядоченным. 
Насколько быстр алгоритм быстрой сортировки? В наилучшем возможном случае: 


на первом этапе и элементов разбиваются на две группы примерно по 1/2 
элементов в каждой; 


на втором этапе две группы по примерно 7/2 элементов разбиваются на четыре 
по примерно п/4 элементов; 


далее четыре группы разбиваются на восемь по 7/8 элементов и т.д. 


Процесс протекает примерно в І06,и этапов, так что общий объем операций в наилуч- 
шем случае пропорционален и+2хи/2 +4хп/4 +8 хи/8... (105,п слагаемых), что 
составляет л [05,и. В среднестатистическом случае эта процедура лишь немногим более 
трудоемка. Логарифм по основанию 2 — это стандарт, поэтому основание можно не пи- 
сать и считать, что затраты времени на быструю сортировку пропорциональны и |057. 

Данная реализация быстрой сортировки наиболее удобна для демонстрации, но в 
ней есть и слабые места. Если при каждом выборе опорного элемента элементы разби- 
ваются на две почти одинаковых по численности группы, то выполненный нами ана- 
лиз правилен; однако если разбиение на группы часто оказывается слишком неравно- 
мерным, то время работы растет примерно по закону т’. В нашей реализации опорный 
элемент выбирается случайно. Это снижает вероятность того, что необычность вход- 
ных данных приведет к слишком большому количеству неравномерных разбиений. 
Ноесли все исходные данные одинаковы, то в нашем варианте каждый раз от группы 
будет отделяться всего один элемент, и время работы приобретет порядок т’. 
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Эффективность работы некоторых алгоритмов сильно зависит от исходных дан- 
ных. Случайно или преднамеренно искаженный характер данных может привести к 
тому, что вполне стабильный алгоритм вдруг станет работать очень медленно или 
использовать слишком много памяти. В случае быстрой сортировки наша простей- 
шая реализация иногда работает слишком медленно, однако более совершенные 
варианты сводят вероятность аномального поведения алгоритма почти к нулю. 


2.3. Библиотечные средства 


Стандартные библиотеки С и С++ содержат функции сортировки, которые ведут 
себя устойчиво по отношению к любым входным данным и развивают максимально 
возможное быстродействие. 

Библиотечные функции предназначены для сортировки данных любого типа, 
однако взамен пользователь должен приспособиться к их интерфейсу, который час- 
то бывает несколько сложнее, чем рассмотренный ранее. В языке С библиотечная 
функция называется азогЕ, и для ее работы необходимо подготовить функцию 
сравнения, которая будет вызываться из азогі всякий раз, когда необходимо срав- 
нить два значения. Поскольку значения могут иметь любой тип, в функцию сравне- 
ния передаются два указателя типа уоіа* на сравниваемые элементы данных. 
Функция приводит указатели к требуемому типу, извлекает значения данных, срав- 
нивает их и возвращает результат (отрицательный, нулевой или положительный, 
в зависимости от того, является ли первое значение большим, равным или меньшим, 
чем второе). 

Ниже показан вариант, предназначенный для сортировки массива строк (это час- 
то встречающаяся задача). Определим функцию ѕстр, которая приводит аргументы 
к нужному типу и вызывает функцию ѕёгстр для непосредственного сравнения: 


/* встр: сравнение строк *р1 и *р2 */ 
іп зстр(сопзЕ уоіа *р1, сопѕі уоіа *р2) 


срахк *у1, *у2; 


у1 = *(сһаг **) рі; 
У2 = *(сһаг **) р2; 
геёџоүп ѕігстр (у1, у2); 


} 


Все это можно было бы записать в одну строчку, но код читать удобнее с приме- 
нением временных переменных. 

Чтобы отсортировать элементы от ѕёг [0] до зЕх[М-1] в массиве строк, 
в функцию азогЕ следует передать такие аргументы, как сам массив, его длина, 
размер сортируемых элементов и указатель на функцию сравнения: 


срак *5іү [№]; 
аѕогЕ (зір, М, ѕілеоЁ (ѕіг[0]), стр); 


Функцию ѕёгстр нельзя использовать непосредственно как функцию сравне- 
ния, потому что азотхе перебирает адреса всех элементов в массиве в виде &56ү [1] 
типа сһаг**,ане зёг [1] типа сһаг*, как показано на этом рисунке: 
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массив из М указателей: 


ѕЕг[] — ап 
$6 [1] | 
Ег [2] Е 
реє: 
ѕёү [3-1] —_——— ы 5311198 


А вот аналогичная функция істр для сравнения целых чисел: 


/* іспр: сравнение целых чисел *р1 и *р2 */ 
іп 1стр(сопзЕ уоіа *р1, сопзі уоіа *р2) 


{ 


іп \1, у2; 


у1 = *(іпі *) рі; 
у2 = *(іпі *) р2; 
ТЕ (у1 < у2) 
тебагп -1; 
е1ѕе 1Е (у1 == у2) 
геіцџгп 0; 
е1зе 
геіџүп 1; 


Можно было бы написать: 


2 геіцүгп у1-у2; 


Но в том случае, если у2 велико и положительно, а у1 — велико и отрицательно 
(или наоборот), получившееся арифметическое переполнение приведет к непра- 
вильному ответу. Непосредственное сравнение длиннее, но безопаснее. 

И в этом случае вызов функции азотЕ требует передачи массива, его длины, 
размера элемента и указателя на функцию сравнения в качестве аргументов: 


іп агг [№]; 
азохе (агг, М, ѕілеоЁ (агг [0]), істр); 


В АМ№І С также определена функция двоичного поиска под именем рѕеагсћ. 
Как и азот, функции рѕеагсћ требуется указатель на функцию сравнения (часто 
это та же самая, что используется в азог Е). Она возвращает указатель на найденный 
элемент или МОТЬ, если элемент отсутствует. Далее приведена функция 1оокир для 
поиска символов НТМТ. в кодовой таблице, переписанная с использованием проце- 
дуры рѕеагсһ. 
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/* 1оокир: ищет строку пате в массиве бар, возвращает индекс */ 
іп 1оокир (сһаг *пате, Матеуа1 бар [], іпё пбаь) 


Матеуа1 Кеу, *пр; 


Кеу.паше = папе; 


Кеу.уа1ае = 0; /* не используется; может быть любым */ 
пр = (Машеуа1 *) Юрѕеаүс|һ (&Ккеу, бар, піар, 
317е0Е (бар [0]), пустр); 


ТЕ (пр == МЈ) 
геїиџгп -1; 
е1зе 
геіџгп пр-ва; 


} 


Как и в случае азохЕ, функция сравнения получает адреса сравниваемых 
элементов, поэтому ключ кеу должен иметь соответствующий тип. В данном приме- 
ре приходится конструировать фиктивную запись Матеуа1, чтобы было что пере- 
дать в функцию сравнения. Сама функция носит имя пустр и сравнивает два эле- 
мента Матеуа1 путем вызова стандартной функции ѕёгстр с ее строковыми ком- 
понентами в качестве аргументов. Числовые значения игнорируются. 


/* пустр: сравнивает два имени типа Машеуа1 */ 
іп пустр (сопзЕ уоіа *уа, сопзЕ уоіа *ур) 


{ 


сопзЕ Матеуа1 *а, *Ъ; 

а = (Матеуа1 *) уа; 

р = (Мамеуа1 *) ур; 

геёџогп зЕгспр(а->паше, р->пате) ; 


} 


Эта функция аналогична зсшр, но отличается тем, что строки представлены в 
виде полей структур. 

Неудобство, связанное с использованием ключа, показывает, что функция 
Ьзеахксй предоставляет пользователю меньшие функциональные возможности, чем 
аѕоге. Хорошая подпрограмма сортировки общего назначения занимает несколько 
страниц кода, тогда как функция двоичного поиска обычно не длиннее, чем те не- 
сколько операторов, которые обеспечивают интерфейс к ней в программе. И тем 
не менее рекомендуется пользоваться рѕеагсћ, а не писать свою собственную 
функцию. Уже в течение многих лет задача двоичного поиска является на удивление 
трудной для большинства программистов. 

Стандартная библиотека С++ содержит нетипизированный алгоритм под назва- 
нием ѕогі, который гарантирует количество операций порядка О(и Іов п). Его ин- 
терфейс проще, чем у рассмотренных функций, потому что он не требует ни приве- 
дения типов, ни знания размера элементов, ни явно заданной функции сравнения, 
лишь бы тип исходных данных предполагал отношение упорядоченности. 


іп агг [№]; 


ѕогЁ (агг, агг+М№) ; 
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В библиотеке С++ также имеются нетипизированные процедуры двоичного 
поиска с теми же преимуществами интерфейса. 


Упражнение 2.1. Самая естественная форма алгоритма быстрой сортировки — 
это рекурсивная. Напишите этот же алгоритм в итерационной форме и сравните две 
его версии. (Ч. Хоар рассказывал, как тяжело было реализовать быструю сортиров- 
ку итерационным способом и как все стало на свои места, стоило только перейти 
к рекурсивной форме.) 


2.4. Быстрая сортировка в Јауа 


Ситуация в языке Јауа несколько отличается от С. В ранних версиях ]ауа не было 
стандартной функции сортировки, и приходилось писать собственные. А вот в более 
новых версиях функция зогЕ уже есть, и она работает с классами, реализующими 
интерфейс Сотрагар1е, так что теперь можно сортировать данные библиотечными 
средствами. Но поскольку сама техника сортировки может пригодиться и в других 
приложениях, далее мы проработаем все детали реализации алгоритма быстрой сор- 
тировки на языке ]ауа. 

Нетрудно адаптировать функцию аџіскѕогіё к данным любых типов, сортиров- 
ка которых может нам понадобиться, но будет более поучительно реализовать про- 
цедуру нетипизированной сортировки, которую можно вызывать для любого объек- 
та, т.е. в стиле интерфейса аѕог+. 

Существенное отличие этого случая от С и С++ состоит в том, что в языке Јауа 
невозможно передать функцию сравнения в другую функцию: там нет указателей на 
функции. Вместо этого создается интерфейс, содержащий одну функцию, которая 
сравнивает два объекта типа ОБ] есЕ. Затем для каждого класса сортируемых дан- 
ных создается класс с методом, реализующим интерфейс для этого конкретного 
типа. Экземпляр этого класса передается в функцию сортировки, которая в свою 
очередь пользуется функцией сравнения из состава класса для того, чтобы сравни- 
вать сортируемые элементы. 

Начнем с определения интерфейса Стр, в котором объявляется один член — 
функция сравнения стр, сравнивающая между собой два объекта Орјес+. 


іпсегҒасе Стр { 
іп спр (Орјесіё х, Орјесё у); 
} 


Теперь можно написать функции сравнения для реализации этого интерфейса. 
Например, в следующем классе определяется функция для сравнения двух объектов 
типа Тосечет: 


// Істр: сравнение объектов Іпіедег 
с1аѕѕ Істр 1пр1ещерез Сир { 
рор1ііс іпі спр (Орјесі о1, Орјесё о2); 
{ 
106 11 = ((Іпёедеү) о1).1п6\Уа1ае(); 
іп 12 ((Іпёедег) о2).1пЕУа1ае (); 
Еа" = 12) 
тебиеп -1; 
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е1зе 1Е (11 == 12) 
геіцџгп 0; 

е1ѕе 
геіцџгп 1; 


} 


В этом классе сравнению подвергаются объекты $6гіпа: 


// $сшр: Зіёгіпо сотрагіѕоп 
с1аѕѕ $стр ітрІетепёѕ Стр { 
рор1іс іп стр (ОБ)]есЕ о1, ОБ]есЕ 02) 
{ 
біргіп 81 (ЗЕх1ра) о1; 
ЗЕх1па 82 = (56к1па) 02; 
геёигп 51.сотрагетТо ($2); 


} 


Таким способом можно сортировать только данные типов, производных от 
Орјесі; элементы базовых типов наподобие іп или доџр1е подобным образом 
отсортировать нельзя. Вот почему в нашем примере мы сортируем объекты класса 
Іпседег, а не типа іп. 

Имея эти компоненты, уже можно перевести функцию аоіскзогі с языка С на 
язык Јауа и сделать так, чтобы она вызывала функцию сравнения из объекта Стр, 
переданного в нее как аргумент. Наиболее существенное изменение состоит во вве- 
дении индексов 1еЕ® и гідћ, поскольку в ]ауа нет указателей на массивы. 


// Фоіскзогі.зѕогі: быстрая сортировка элементов у [1еЁі] ..у[кісһі] 
зЕаЕ1с уоіа зогі (Орјесіё [] у, іп 1ІеЁс, іп главе, Стр стр) 


{ 


іп і, 1азе; 


1Е (1еЕЕ >= үідһё ) // ничего не нужно делать 


геіоүп; 
змар (у, ІеЁё, гапа (1еЁё, гідһё))); // переместить опорный элемент 
1аѕі = 1ІеЁё; // в у[1еЁё] 
Ғог (1 = 1еЁЕ+1; 1 <= гізһі; 1++) // разбиение диапазона 


1Е (стр.стр (\[1], у[ПеЕЕ]) < 0) 
з\ар (у, ++1аѕё, 1); 


ѕмар (у, 1еЕЕ, 1аѕі); // восстановить опорный элемент 
ѕогї (у, 1еЁЕ, 1аѕі-1, стр); // рекурсивная сортировка 
ѕогї (у, Іаѕі+1, хлорЕ, стр); // обеих частей диапазона 


} 


Функция Оиіскѕогі . зог использует функцию стр для сравнения пары объек- 
тов между собой, а затем вызывает ѕмар, как и раньше, чтобы поменять их местами. 
// Оџіскѕогё.ѕмар: поменять местами у[і] и у[5] 


зЕаЕ1с уоіа змар (Орјесё [] у, іпё і, іпё 3) 


{ 


ОБ)есЕ Еепр; 


сетр = у[1]; 
у[1] у[51; 
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у [5] = ёетр; 


Генерирование случайных чисел осуществляется отдельной функцией в диапазо- 
не от 1еЕЕ до гічһіё включительно: 


зЕаЕ1с БВапдот үдеп = пем Вараощ(); 


// Оџіскѕогё.гапа: возвращает случайное целое число 
АА в диапазоне [1еЁі, гідһі] 
зЕаЕ1с іпі гапа (іп ТеЁе, іпё гіздһі) 


геіџоүп 1еЕЕ + Маёһ.арѕ (хаеп.пехЕТие ()) $ (гічһе-1ІеЁё+1); 


} 


Здесь с помощью функции Маһ .арѕ вычисляется абсолютное значение, потому 
что генератор случайных чисел ]ауа выдает и положительные, и отрицательные числа. 

Функции ѕогё, эмар и гапа, а также объект-генератор хдеп являются членами 
класса Оц1сКкзоке. 

Наконец, чтобы воспользоваться функцией Ооіскѕогё . зорі для сортировки 
массива данных типа Ѕёгіпа, запишем следующее: 


ЗЕх1па[] закк = пем Ѕёгіпа [п]; 
// Здесь заполняется п элементов массива ѕагг... 
Оц1сКкзохЕ . зокЕ (ѕагг, 0, ѕагг.1епадёһ-1, пем Ѕстр()); 


В результате этого функция зотЕ вызывается с аргументом в виде объекта для 
сравнения строк, созданного специально для данного случая. 


Упражнение 2.2. Наша реализация быстрой сортировки на Јауа изобилует опе- 
рациями приведения типов, поскольку элементы постоянно преобразовываются из 
их исходного типа (например, Іпбедег) в тип ОБ есь и наоборот. Напишите вер- 
сию Оиіскзогі . ѕогі для сортировки данных вполне определенного типа и поэкс- 
периментируйте с обоими вариантами функции, чтобы выяснить, какое влияние 
на быстродействие оказывают преобразования типов. 


2.5. О-оценка 


Ранее объем операций, выполняемый тем или иным алгоритмом, уже характери- 
зовался через и — количество элементов в наборе исходных данных. Поиск в несор- 
тированных данных требует времени, пропорционального и; если воспользоваться 
алгоритмом двоичного поиска в отсортированных данных, то затрачиваемое время 
окажется пропорциональным 105 п. Время сортировки данных может измеряться 
порядком т или п 105 и. 

Нам необходим способ формулировать подобные зависимости более четко и кон- 
кретно, в то же время абстрагируясь от таких деталей, как быстродействие процессо- 
ра или качество компилятора (а также квалификация программиста). Желательно 
было бы сравнивать время выполнения и требуемые объемы памяти тех или иных 
алгоритмов независимо от языка программирования, компилятора, аппаратной 
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архитектуры, быстродействия процессора, загрузки операционной системы и других 
усложняющих анализ факторов. 

Для этой цели имеется стандартная форма записи или метод оценки, именуемый 
О-оценкой. Основным ее параметром является п, т.е. размер исследуемой задачи, 
причем время выполнения алгоритма или его сложность представляется в виде 
функции и. Буква О представляет собой сокращение от слова о’4ег (“порядок”). Та- 
ким образом, выражение “двоичный поиск имеет характер О(юр и)” означает, что 
требуется порядка [05 и шагов для поиска в массиве из и элементов. Запись О( (п) ) 
означает, что при возрастании и время выполнения алгоритма растет пропорцио- 
нально /(п), например О(п’) или О(п1о5 п). Подобные асимптотические оценки иг- 
рают большую роль в теоретическом анализе, а также очень помогают при грубом 
сравнении алгоритмов, но на практике возникают значительные отличия в деталях. 
Например, алгоритм порядка О(п”) с небольшим коэффициентом пропорционально- 
сти может работать быстрее, чем алгоритм порядка О(и [05 п) с высоким коэффици- 
ентом для относительно малых и, но по мере роста и преимущество будет оставаться 
за алгоритмом с медленнее растущей функцией в О-оценке. 

Следует также различать поведение алгоритмов в наихудшем и среднестатисти- 
ческом случаях. Что такое “среднестатистический случай”, определить довольно 
трудно, поскольку это зависит от предполагаемого характера входных данных. Наи- 
худший случай обычно можно определить более-менее точно, хотя он легко может 
дезориентировать программиста. Например, для алгоритма быстрой сортировки 
наихудший случай соответствует количеству операций порядка О(п’), а его среднее 
быстродействие характеризуется оценкой О(п Іов п). Всякий раз тщательно выбирая 
опорный элемент, можно свести вероятность квадратичного, т.е. О(и’), объема опе- 
раций практически к нулю. На практике хорошо написанная процедура быстрой 
сортировки почти всегда выполняет порядка О(и [ов п) операций. 

Ниже приведены наиболее важные на практике порядковые оценки. 


Оценка Характер зависимости Пример операции 

0(1) Постоянная Обращение по индексу 
О(05п) Логарифмическая Двоичный поиск 

О(п) Линейная Сравнение строк 

О(п Іов п) Пропорциональная п 105 и Быстрая сортировка 
О(т?) Квадратичная Простая сортировка 
0(т) Кубическая Умножение матриц 
002") Экспоненциальная Разбиение на группы 


Обращение к элементу в массиве имеет порядок О(1) т.е. не зависит от количест- 
ва элементов. Алгоритм, который на каждом шаге отбрасывает половину оставшихся 
данных, наподобие двоичного поиска, обычно требует О(1о5 т) операций. Сравнение 
двух строк из м элементов с помощью функции зёгстр имеет характер О(п). Тради- 
ционный алгоритм умножения матриц отнимает О(т`) времени, поскольку каждый 
элемент на выходе образуется путем перемножения и пар исходных элементов и 
сложения результатов, а всего в матрице и’ элементов. 
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Алгоритмы с экспоненциальным порядком количества операций часто включают в 
себя вычисление или перебор всех возможных сочетаний и вариантов. Так, в множест- 
ве из п элементов имеется 2" подмножеств, поэтому если в алгоритме выполняется пе- 
ребор по всем подмножествам, то он имеет характер О(2”). Экспоненциальные алго- 
ритмы обычно обходятся слишком дорого, если и достаточно велико, потому что до- 
бавление в задачу всего одного элемента удваивает количество операций. К сожале- 
нию, существует немало задач, в том числе знаменитая “задача коммивояжера”, для 
решения которых известны только алгоритмы экспоненциального порядка. Если необ- 
ходимо решить именно такую задачу, очень часто прибегают к альтернативным мето- 
дам, которые дают то или иное приближение к точному правильному ответу. 


Упражнение 2.3. Выясните, какие исходные данные являются наихудшими для 
алгоритма быстрой сортировки. Попытайтесь найти несколько массивов данных, 
которые бы заставили библиотечную реализацию этого алгоритма работать как 
можно медленнее. Автоматизируйте процесс экспериментирования так, чтобы под- 
бор и анализ исходных данных выполнялись сами по себе. 


Упражнение 2.4. Разработайте и реализуйте алгоритм, сортирующий массив из и 
целых чисел как можно медленнее. Играть нужно честно: алгоритм должен посте- 
пенно сходиться к результату и успешно заканчиваться; нельзя применять такие об- 
манные трюки, как холостые прогоны циклов специально для задержки времени. 
Какой порядок имеет этот алгоритм по отношению к количеству элементов и? 


2.6. Расширяемые массивы 


В предыдущих разделах использовались статические массивы, т.е. такие, размер и 
содержимое которых фиксировались еще на этапе компиляции. Если бы таблицы 
“слов-паразитов” или символов НТМГ приходилось модифицировать в процессе 
выполнения программы, то в качестве базовой структуры данных больше подошла 
бы хэш-таблица. Добавление в отсортированный массив и элементов по одному за 
раз является операцией порядка О(п’), и ее лучше избегать при больших и. 

Тем не менее иногда бывает необходимо держать все данные непостоянного объ- 
ема в одной составной переменной, причем этих данных не должно быть слишком 
много. Самой удачной структурой данных для подобной задачи по-прежнему оста- 
ется массив. Чтобы минимизировать затраты на распределение памяти, приращение 
массива следует выполнять блоками, и для поддержания хорошего стиля програм- 
мирования массив нужно хранить вместе со статистической информацией, необхо- 
димой для его обработки. В языках С++ и Јауа это делается с помощью классов из 
стандартных библиотек, ав С — с помощью структур. 

В приведенном ниже фрагменте определяется растущий массив элементов типа 
Матеуа1; новые элементы добавляются в конец массива, который расширяется по 
мере необходимости. Имеется возможность обратиться к любому элементу массива 
по его индексу за фиксированное время. Получается некий аналог векторных клас- 
сов из библиотек Јауа и С++. 
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СуреаеЕ зЕхгасЕ Машеуа1 Машеуа1; 
ЗЕГИСЕ Матеуа1 { 

сһаг *паме; 

іпё уа1іпе; 


}; 


зегисё Мубар { 


іпё пуа1; /* текущее количество элементов */ 
ПЕ птах; /* количество выделенных ячеек */ 
Матеуа1 *патеуа1; /* массив пар "имя-значение" */ 


} 


епот ( МУТМТТ = 1, МУСРОМ = 2 }; 


/* аддапате: добавляет новое имя и значение в структуру пубар */ 
іп ааапате (Мамеуа1 пемпате) 


{ 


Матеуа1 *пур; 


1Е (пубар.патеуа1 == МОШ) { /* первый раз */ 
пусар.патеуа1 = 
(Матеуа1 *) та11ос (МУТМТТ * ѕіхлеоЁ (Мамеуа1)) ; 
1Е (пуёбар.патеуа1 == МО) 
геёџүп -1; 
пусар.тах = МУТМТТ; 
пусар.пуа1 = 0; 
} е15е 1Е (пубар.пуа1 >= пубар.тах) { /* расширение */ 
пур = (Машеуа1 *) геа11ос (пуёар.патеуа1, 
(МУСРОК*пусар.тах) * з12еоЕЁ (Матеуа1)) ; 
ТЕ (пур == МО) 
геёџүп -1; 
пусар.тах *= МУСВОИ; 
пусар.патеуа1 = пур; 


} 


пуёар.патеуа1 [пуёар.пуа1] = пемпаме; 
геіигп пубар.пуа1++; 


} 


Функция аддпате возвращает индекс только что добавленного элемента или -1, 
если произошла ошибка. 

При вызове функции геа11ос массив расширяется до нового размера, сохраняя 
все уже имеющиеся в нем элементы. Возвращается указатель на новый буфер или 
МО11,, если оказалось недостаточно памяти. Удвоение размера массива при каждом 
вызове хеа11ос позволяет сохранить постоянным средний объем операций по ко- 
пированию одного элемента. Если бы при каждом вызове этой функции добавлялась 
всего одна ячейка, время таких операций имело бы порядок О(п’). Поскольку адрес 
массива может изменяться при перераспределении памяти, в остальной части про- 
граммы следует обращаться к элементам по индексам, а не через указатели. Обрати- 
те внимание, что в коде не употребляется такая конструкция: 


? пуёар.патеуа1 = (Маме\уа1 *) хкеа11ос (пуёар.патеуа1, 
? (МУСРОИ*пуёар.тах) * ѕілеоЁ (Матмеуа1)) ; 
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В этом случае, если бы при перераспределении памяти произошла ошибка, 
все накопленные в исходном массиве данные были бы потеряны. 

Работа начинается с массива очень малого исходного размера (МУТМТТ = 1). 
Это заставляет программу немедленно расширить его и таким образом гарантирует, 
что данный блок программы сработает. Первоначальный размер массива можно и уве- 
личить перед тем, как выпускать программу для профессионального использования, 
но, вообще-то, затраты на инициализацию не так уж велики, чтобы об этом беспокоиться. 

Возвращаемое из геа11ос значение не обязательно приводить к его окончатель- 
ному типу, потому что в языке С это делается с указателями *уоіа автоматически. 
А вот в С++ это не так; там явное приведение типа необходимо. Можно поспорить о 
том, что безопаснее: приводить типы (это более явная запись, в хорошем стиле) или 
не приводить (приведение типов может скрыть различные тонкие ошибки). Мы ре- 
шили включить в функцию приведение типов, чтобы сделать код безошибочным с 
точки зрения как С, так и С++. В результате компилятор С менее тщательно прове- 
ряет ошибки, но это уравновешивается дополнительной возможностью проверки 
сразу двумя компиляторами. 

Удаление имени из массива может оказаться довольно хитрой задачей, поскольку 
нужно решить, что делать с освободившейся ячейкой. Если порядок элементов не 
имеет значения, то легче всего перебросить последний элемент в образовавшуюся 
свободную позицию. Если же порядок необходимо соблюсти, то придется сдвинуть 
на одну ячейку назад все элементы после свободной позиции: 


/* де1пате: удаление первой найденной строки пащеуа1 из массива 
пубаь */ 
іп ае1паме (сһаг *паме) 


{ 


106 і; 
Ғог (1 = 0; і < пуёар.пуа1; 1++) 
1Е (ѕігстр (пуёар.патеуа1 [1] .пате, пате) == 0) { 
петтоуе (пуёар.патеуа1+і, пуіар.патеуаї+і+1, 
(пусар.пуа1- (1+1)) * ѕілеоЁ (Мамеуа1)); 

пуёар.пуа1--; 
геіцџүп 1; 

геіцџгп 0; 


} 


При вызове функции теттоуе массив “сдавливается”, сдвигаясь внутрь себя на 
одну позицию. Эта функция принадлежит к стандартной библиотеке и предназначе- 
на для копирования блоков памяти произвольной длины. 

В стандарте АМЗТ С определены две функции: тетсру, которая работает быстро, 
но затирает память, если буфер-источник и буфер назначения перекрываются; и 
петтоуе, работающая медленнее, зато неизменно правильно. Бремя выбора между 
правильностью и быстродействием не следовало бы возлагать на программиста, так 
что в идеале функция должна быть только одна. Представим себе, что так оно и есть, 
и всегда будем пользоваться тептоуе. 
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Вызов функции теттоуе можно было бы заменить следующим циклом: 


106 ј; 
Ғог (5 = 1; ј < пуёбар.пуа1-1; ј++) 
пуа1.папеуа1 [5] = пуёар.патеуа1 [5+1]; 


Мы предпочитаем теттоъуе, потому что ее использование позволяет избежать 
характерной ошибки копирования элементов в неправильном порядке. Если бы вы- 
полнялась вставка, а не удаление, элементы было бы необходимо перебирать в об- 
ратном порядке, чтобы не затереть их. Вызывая теттоуе, мы избавляемся от необ- 
ходимости всякий раз думать об этом. 

Подход, альтернативный перемещению элементов в массиве, — это пометить 
удаленные элементы как неиспользуемые. Затем, чтобы добавить новый элемент, 
вначале необходимо найти свободную ячейку, и только в том случае, если таковых 
нет, расширить массив до нового размера. В данном примере, чтобы пометить эле- 
мент как неиспользуемый, в его поле пате можно записать значение МОЦ. 

Массивы — это простейший способ группировки данных. Неудивительно, что во 
многих языках имеются эффективные и удобные средства для их хранения и индек- 
сации и что строки представляются именно массивами символов. Массивы просты в 
использовании, требуют О(1) операций для обращения к любым элементам, отлично 
подходят для применения двоичного поиска и быстрой сортировки, компактно хра- 
нятся в памяти. Для целей хранения наборов данных фиксированного размера, фор- 
мируемых в процессе компиляции, или относительно небольших совокупностей 
элементов переменной длины массивы не знают себе равных. Но работа с постоянно 
меняющимся набором элементов в массиве переменной длины может отнять много 
времени и ресурсов, поэтому если количество элементов непредсказуемо и может 
стать очень большим, то лучше обратиться к другим структурам данных. 


Упражнение 2.5. В приведенном выше коде функция де1пате не вызывает 
функцию геа11ос, чтобы возвратить память, освободившуюся при удалении. Стоит 
ли это делать? Как бы вы определили, делать это или нет? 


Упражнение 2.6. Внесите необходимые изменения в функции аййпате и 
де1пате так, чтобы удалять имена, помечая их как неиспользуемые. Насколько 
остальная часть программы изолирована от этих изменений? 


2.7. Списки 


Вслед за массивами самыми распространенными структурами данных в про- 
граммах являются списки. Во многих языках есть встроенные списковые типы дан- 
ных, а некоторые языки (такие как Ііѕр) вообще основаны на списках. Но в языке С 
приходится конструировать их самостоятельно. В С++ и Јауа имеются библиотеч- 
ные реализации списков, но все равно нужно знать, когда и как ими пользоваться. 
В этом разделе рассматриваются списки в С, но эта информация может пригодиться 
и в более широком контексте. 
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Однонаправленный список — это набор элементов, каждый из которых состоит из 
хранимых данных и указателя на следующий элемент. Голова списка указывает на 
его первый элемент, а конец списка обозначается нулевым указателем. Здесь пока- 
зан список из четырех элементов: 


голова 
списка 


= >= = = Ш 


данные 1 данные 2 данные 3 данные 4 


Между массивами и списками есть несколько важных различий. Во-первых, мас- 
сив имеет фиксированную длину, тогда как список — в точности такую, какая нужна 
для хранения всех его данных, плюс некоторое дополнительное пространство для 
хранения указателей. Во-вторых, список можно переупорядочить, всего лишь поме- 
няв местами несколько указателей, что гораздо удобнее, чем перемещать туда-сюда 
блоки данных. Наконец, при добавлении или удалении новых элементов остальные 
элементы никуда не перемещаются. Если, например, указатели на элементы списка 
хранятся в какой-то другой структуре данных, то ни один из них не потеряет свой 
смысл при добавлении новых элементов. 

Все эти различия подсказывают, что если набор данных должен часто изменять- 
ся, в частности, если количество элементов заранее не предсказуемо, то такие дан- 
ные следует организовать в виде списка. А вот массив больше подходит для сравни- 
тельно статичных данных. 

Имеется всего лишь несколько базовых операций над списком: добавление ново- 
го элемента в начало или в конец списка; поиск элемента; добавление нового эле- 
мента перед определенным или после него; иногда удаление элемента. Простота уст- 
ройства списков позволяет по необходимости добавлять дополнительные операции. 

Вместо того чтобы определять отдельный тип 11%, в языке С обычно берут 
структурный тип данных для хранения элементов (например, рассмотренный выше 
Матеуа1) и добавляют указатель для связи со следующим элементом: 


сСуреаеЕ зЕкасЕ Машеуа1 Матеуа1; 
ѕігосё Матеуа1 { 


сһаг *паме; 
ре уаіпое; 
Матеуа1 *пехі; /* следующий в списке */ 


}; 


Непустой список трудно инициализировать на этапе компиляции, поэтому в 
отличие от массивов списки чаще создаются динамически. Вначале необходимо 
получить возможность конструировать элементы. Самый прямой способ — это вы- 
полнить распределение памяти соответствующей функцией, которую мы назовем 
пем1 Сет: 


/* пеміёет: создает новый элемент по имени и значению */ 
Матеуа1 *пем1еет(сраг *паме, іпі уа1ае) 


{ 


Матеуа1 *пемр; 


пемр = (Матшеуа1 *) епа11ос (ѕілеоғ (Матеуа1)); 
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пемр->паше = папе; 
пеир->уа1ае = уа1ае; 
пемр->пехі = МОЦ; 
геіоџгп пемр; 


} 


Функция ета11ос будет часто использоваться в этой книге. В ней вызывается 
та110ос, а если при распределении памяти происходит ошибка, то выводится сооб- 
щение об ошибке и программа завершается. Ее код будет приведен в главе 4, а пока 
будем воспринимать ее как функцию распределения памяти, никогда не дающую 
ошибочного результата. 

Самый простой и быстрый способ собрать список — это добавлять каждый новый 
элемент по очереди в голову списка: 


/* аааЕхопе: добавляет пемр в голову списка 1іѕёр */ 
Матеуа1 *ааағгопё (Матеуа1 *11з6р, Матеуа1 *пемр) 


пемр->пехі = 115®ер; 
гесогп пемр; 


} 


При модификации списка его первый элемент может измениться, как это и про- 
исходит в случае вызова функции аааѓёгопі. Функции, модифицирующие список, 
должны возвращать указатель на его новый первый элемент, который хранится в 
переменной, обозначающей весь список в целом. Функция аЧ9я9ЕкопЕ и другие 
функции в этой группе возвращают указатель на первый элемент; типичный способ 
их вызова имеет вид 


пу1іѕі = аааЁкопе (пу1іѕё, пемібет ("ѕтмі1еу", 0х263А)); 


Эта конструкция работает даже в том случае, если существующий список — 
пустой (нулевой), и позволяет легко комбинировать функции в выражениях. 
Она удобнее, чем альтернативный способ с передачей указателя на указатель, 
содержащий голову списка. 

Добавление элемента в конец списка — это операция порядка О(п), поскольку 
список необходимо сначала перебрать от начала до конца: 


/* айдепа: добавляет пемр в конец списка 1136р */ 
Матеуа1 *аддепа (Матеуа1 *1іѕёр, Матеуа1 *пемр) 


{ 


Матеуа1 *р; 


1Е (1іѕёр == МО) 
геіогп пемр; 
Ғог (р = 1ізір; р->пехЕ != МОЦ; р = р->пехі) 


; 
р->пехЕ = пемр; 
гесигп 1іѕір; 


} 


Если нужно придать функции аааепа характер О(1) по быстродействию, можно 
завести отдельный указатель на конец списка. Недостаток этого подхода, кроме 
необходимости хранить и отслеживать хвостовой указатель, состоит в том, что спи- 


64 Алгоритмы и структуры данных Глава 2 


сок больше нельзя будет представить одной-единственной адресной переменной. 
Поэтому будем придерживаться более простого стиля. 

Для поиска элемента с тем или иным именем следует пройти по цепочке указате- 
лей пехі: 


/* Тоокар: последовательный поиск имени пате в списке 1іѕзір */ 
Матеуа1 *1оокир (Матеуа1 *115Ер, сһаг *паме) 


Ғор ( ; Іізѕір != МО; 1іѕер = 1іѕір->пехі) 
1Е (ѕігстр (пате, 1іѕёр->пате) == 0) 
геёигп 1ізір; 
геёоџоүп МОГ; /* элемент не найден */ 


} 


Эта операция занимает О(п) времени, и в целом улучшить ее быстродействие не 
представляется возможным. Даже если список отсортирован, все равно необходимо 
перебрать его последовательно для нахождения нужного элемента. Двоичный поиск 
к спискам неприменим. 

Для вывода всех элементов списка можно написать функцию, которая бы пере- 
бирала его и последовательно выводила каждый элемент. Чтобы вычислить длину 
списка, можно написать функцию с простым перебором и инкрементированием 
счетчика. Есть и альтернативный подход — написать функцию арр1у, выполняю- 
щую перебор списка и вызывающую другую заданную функцию для каждого его 
элемента. Функцию арр1у можно сделать очень гибкой, включив в ее параметры 
аргумент для передачи в ту, другую функцию. Итак, арр1у будет принимать три 
аргумента: сам список; указатель на функцию, вызываемую для каждого элемента 
списка; аргумент для передачи в эту функцию. 


/* арр1у: выполняет Ёп для каждого элемента списка 1іѕір */ 
уоіа арр1у(Матеуа1 *11ізѕір, 


уоіа (*#п) (Матеуа1*, уоій*), уоіа жаг) 

{ 
Ғог ( ; Іізѕір != МО; 1іѕер = 1іѕір->пехі) 
(*Еп) (1іѕёр, ага); /* вызов функции */ 


} 


Второй аргумент функции арр1у — это указатель на функцию, которая прини- 
мает два аргумента и возвращает уоіа. Она имеет довольно неуклюжий, хотя и 
стандартный синтаксис: 


уоіа (*#п) (Мамеуа1*, уо1а*) 


Здесь Еп объявляется как указатель на функцию, возвращающую пустое значе- 
ние уоіа, т.е. это переменная, содержащая адрес функции, которая ничего не воз- 
вращает. Функция принимает два аргумента. Один из них — это указатель на эле- 
мент списка Матеуа1*, а второй — нетипизированный указатель на аргумент для 
передачи в вызываемую функцию. 

Чтобы использовать арр1у, например, для вывода элементов списка, можно 
написать тривиальную функцию с аргументом в виде строки формата: 
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/* рүіпіпу: вывести имя и значения по строке формата ага */ 
уоіа ргіпёпу (Машеуа1 *р, уоіа *ага) 


{ 


сһаг *ЕшЕ; 


Ете = (сВах *) ага; 
рке1рЕЕ (Ёт, р->пате, р->уа1ае); 


В данном случае функция арр1у вызывается таким образом: 
арр1у (пу1іѕё, ргріпёпу, "%5: %х\п"); 
Для подсчета элементов определяется функция с аргументом в виде указателя на 
целочисленный счетчик, который нужно инкрементировать: 


/* 1оссоцреег: инкрементирует счетчик *ага */ 
уоіа 1пссочпеек (Матеуа1 *р, уоіа *агү9) 


106 *ір; 


/* р не используется */ 
ір = (116 *) ага; 
(*1р) ++; 


Эта функция вызывается следующим образом: 
іпё п; 
Т. =1:0:5 


арріу (пу1іѕі, іпссоџпіег, &п); 
ргіпіЁ ("%а е1етепіѕ іп пу1іѕё\п", п); 


Не каждую операцию со списком можно реализовать в таком виде. Например, 
для уничтожения списка необходимо действовать более осторожно: 


/* Егееа11: освобождение всех элементов списка 1іѕір */ 
уоіа Ёгееа11 (Матеуа1 *1ізѕір) 


Матеуа1 *пехё; 
Еог ( ; 1156р != МОШ; 1156р = пехё) { 
пехі = Іізір->пехі; 


/* пате освобождается в другом месте */ 
Егее (11іѕір); 


} 


Содержимое памяти нельзя использовать после ее освобождения, поэтому 
1іѕір->пехі необходимо сохранить в локальной переменной под именем пехі 
прежде, чем освобождать элемент, на который указывает переменная 1іѕёр. Почему 
нельзя записать этот цикл, как и прежде, в следующем виде? 


? Еог (; 1156р != МОШ; 1156р = пехё) { 
? Етее (11іѕір); 
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В этом случае значение 11зЕр->пехЕ пропадет при вызове функции Ёгее, и 
произойдет ошибка. 

Обратите внимание, что функция Етееа11 не освобождает поле 11зЕр->папе. 
Предполагается, что поле пате каждого объекта Матеуа1 освобождается где-то в 
другом месте или же что память для него вообще не отводилась. Чтобы распределе- 
ние и освобождение памяти для элементов происходило по единой схеме, необходи- 
мо согласовать между собой функции пем1 сет и Егееа11. Необходимо найти ком- 
промисс, гарантирующий освобождение памяти и в то же время сохранение тех эле- 
ментов, которые нужно сохранить в памяти. В подобных случаях очень часто 
возникают ошибки. В других языках, таких как Јауа, эту проблему автоматически 
решает механизм сборки мусора. Мы еще вернемся к теме управления ресурсами в 
главе 4. 

Удаление одного элемента из списка требует большего труда, чем добавление: 


/* де1іёет: удаляет первое имя пате из списка 1ізір */ 
Матеуа1 *де1іёет (Матеуа1 *1іѕір, сһаг *пате) 


{ 


Матеуа1 *р, *ргеу; 


ргеу = МОЦ; 


Ғог (р = 1іѕер; р != МО; р = р->пехё) { 
1Е (ѕігстр (пате, р->пате) == 0) { 
1Е (рүеу == МОШ) 
1ізѕзір = р->пехі; 
е1зе 
ргеу->пехі = р->пехі; 
Ғгее (р); 


геіогп 1136р; 


} 


ргеу = р; 


} 


ерх1рЕЕ ("ае116ет: %5 поб іп 11536", папе); 
геёџоүгп МОЦ; /* сюда управление не доходит */ 


} 


Как и Ехееа11, функция 9е1 16 ет не освобождает поля пате. 

Функция ергіпё# выводит на экран сообщение об ошибке и завершает работу 
программы. Это неуклюже, если не сказать больше. Корректная обработка ошибок 
представляет собой довольно трудную задачу и требует более подробного обсужде- 
ния, которое мы отложим до главы 4. В главе 4 также будет продемонстрирована 
реализация функции ергіпі#. 

Этих базовых структур и операций со списками вполне достаточно для реализа- 
ции подавляющего большинства распространенных алгоритмов. Но есть и ряд 
альтернативных средств. Некоторые библиотеки, например стандартная библиотека 
шаблонов ($ТІ) языка С++, поддерживают двунаправленные списки, в которых 
каждый узел содержит два указателя — на следующий и предыдущий элементы. 
В двунаправленных списках несколько больше дополнительные затраты памяти, но 
зато операции нахождения последнего элемента и удаления текущего имеют харак- 
тер О(1). В некоторых версиях указатели списков хранятся отдельно от данных, ко- 
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торые они связывают в список. Такие списки сложнее в обращении, но зато позво- 
ляют включать одни и те же элементы сразу в несколько разных списков. 

Кроме того, что списки хорошо подходят для тех задач, где выполняется вставка 
и удаление элементов из середины структуры данных, они еще удобны для управле- 
ния неупорядоченными данными варьирующегося объема, особенно если обращение 
к ним выполняется в стековом стиле — “последним вошел, первым вышел”. Списки 
обеспечивают более эффективное использование памяти, чем массивы, в тех случа- 
ях, когда сразу несколько стеков должно расширяться и сокращаться независимо 
друг от друга. Удобно применять списки и тогда, когда данные упорядочены ориги- 
нальным способом, а их объем неизвестен априори, как это бывает в случае цепочки 
слов в текстовом документе. Но если приходится сочетать частое обновление дан- 
ных с возможностью прямого доступа к ним, то лучше прибегнуть к структуре дан- 
ных с менее ярко выраженной линейностью, например, к дереву или хэш-таблице. 


Упражнение 2.7. Реализуйте некоторые из других возможных операций со спи- 
ском: копирование, слияние, разбиение, вставку перед конкретным элементом или 
после него. Как две различные операции вставки отличаются друг от друга по слож- 
ности? В какой степени можно воспользоваться приведенными выше функциями, 
а что придется написать самостоятельно? 


Упражнение 2.8. Напишите рекурсивную и итерационную версии функции 
теуетзе, которая бы изменяла порядок следования элементов в списке на противопо- 
ложный. Не создавайте новых элементов списка — используйте только существующие. 


Упражнение 2.9. Напишите нетипизированное определение типа 113 на языке 
С. Самый простой способ — это включить в состав каждого элемента списка указа- 
тель на данные типа уоіа*. Проделайте то же самое на языке С++ в виде шаблона, 
а также на ]ауа, определив класс для списка, содержащего элементы типа ОБ)есе. 
Каковы сильные и слабые стороны разных языков в реализации этой задачи? 


Упражнение 2.10. Придумайте и реализуйте набор тестов для проверки правиль- 
ности написанных вами функций работы со списками. Стратегия и тактика тестиро- 
вания рассматриваются в главе 6. 


2.8. Деревья 


Дерево — это еще одна иерархическая структура данных, содержащая набор 
элементов. Каждый элемент содержит значение определенного типа, может указы- 
вать на один, нуль или несколько других элементов, и при этом на него указывает 
только один другой элемент. Исключение составляет корень дерева — на этот эле- 
мент не указывает никакой другой. 

Существует много типов деревьев, соответствующих сложным структурам дан- 
ных из практических задач, — например, синтаксическое дерево, описывающее син- 
таксис предложения или оператора языка, или фамильное дерево, описывающее 
родственные отношения между людьми. Мы проиллюстрируем общие принципы на 
примере двоичных деревьев (точнее, деревьев двоичного поиска), которые в каждом 
узле имеют ровно две связи. Такие деревья легче всего реализовать, и при этом они 
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демонстрируют все существенные свойства этого класса структур данных. Каждый 
узел в двоичном дереве содержит значение и два указателя, 1еЕЕ и гічһ, указы- 
вающие соответственно на левый и правый дочерние узлы. Один или оба из этих 
указателей могут быть равны МОТ, если узел имеет менее двух потомков. В дереве 
двоичного поиска значения в узлах полностью определяют структуру дерева: все 
потомки слева от какого-либо узла имеют меньшие значения, а все потомки справа 
от него — большие. В силу этого свойства в таком дереве можно использовать вари- 
ант алгоритма двоичного поиска для быстрого нахождения узла по значению. 

Вариант структурного типа Матеуа1 для использования в дереве строится 
очень легко: 


СуреаеЕ зЕгисЕ Матеуа1 Матеуа1; 
ѕігисё Матеуа1 { 


срак *папе; 
іпі уа1хое; 
Матеуа1 *1еЕё; /* меньш значение */ 


Матеуа1 *гідһё; /* большее значение */ 


А 


Комментарии о меньшем и большем значениях соответствуют свойствам связей в 
таком дереве: в левых потомках узла хранятся меньшие значения, тогда как в пра- 
вых — большие, чем в самом узле. 

Ниже на рисунке приведен конкретный пример дерева — подмножество таблицы 
символов и их имен, организованное в виде двоичного дерева узлов типа Матеуа1, 
отсортированных по АЗСП-кодам символов. 


"зи11Теу" 
х263А 
"Аасисе" "2еба" 
хет х3рб 
"АЕ1ід" "Асігс" 
хсб хс2 


Поскольку в каждом узле имеются два указателя на другие элементы дерева, мно- 
гие операции порядка О(и) в списках или массивах имеют характер О(105 и) в деревь- 
ях. Наличие двух указателей существенно уменьшает объем операций по перебору 
дерева, поскольку сужает круг узлов, перебираемых для нахождения элемента. 
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Дерево двоичного поиска (далее будем называть его просто “деревом”) строится 
таким образом: выполняется рекурсивный спуск с разветвлением влево или вправо, 
пока не найдется подходящее место для вставки нового узла. Узел должен представ- 
лять собой корректно инициализированный объект типа Матеуа1 с именем, значе- 
нием и двумя пустыми указателями. Новый узел добавляется в виде листа дерева, 
временно не имея потомков. 


/* іпѕегё: вставляет пемр в дерево ігеер, возвращает ігеер */ 
Матеуа1 *іпѕегі (Матеуа1 *Ехеер, Матеуа1 *пемр) 


{ 


106 стр; 


1Е (Ехеер == МО) 

гесигп пемр; 
спр = зЕгспр (пемр->паше, ёгеер->патпе) ; 
1Е (стр == 0) 

мерх1о ЕЕ ("іпѕегі: аџр1ісаёбе епёгу %5 ідпогеа", 

пемр->пате) ; 

е1зе 1Е (стр < 0) 

Сүеер->1еЁс = іпѕегіё (ігеер->1ІеЁё, пемр); 
е1зе 

Сүеер->гідһі = іпѕегі (ёгеер->гідһё, пемр); 
гесигп ёгеер; 


Ранее мы ничего не сказали о дублирующихся записях в дереве. Данная версия 
функции іпѕеге сообщает о попытке вставить в дерево дублирующийся узел 
(при стр == 0). Функция вставки нового элемента в список ничего подобного не 
делала, поскольку для этого следовало бы перебрать весь список, и операция вставки 
приобрела бы характер О(и), а не О(1). А вот в случае дерева, во-первых, такая про- 
верка не требует дополнительных усилий, и, во-вторых, качество всей структуры 
данных пострадало бы от наличия дублирующихся записей. Правда, иногда бывает 
полезно разрешить вставку дублирующихся записей или же вообще игнорировать 
факт дублирования. 

Функция мерт1рЕЕ представляет собой вариант ергіпёғ. Она выводит сооб- 
щение об ошибке, в начале которого стоит слово магпіпа (“предупреждение”), но в 
отличие от ергіпі# не завершает работу программы. 

Дерево, в котором любой путь от корня к листу имеет примерно одинаковую 
длину, называется сбалансированным. Преимущество сбалансированного дерева 
заключается в том, что поиск по нему имеет характер О(1о5 п), поскольку, как и в 
двоичном поиске, на каждом шаге отбрасывается половина оставшихся данных. 

Если узлы добавляются в дерево по мере их поступления, дерево может оказаться 
несбалансированным; более того, оно может стать исключительно разбалансированным. 
Например, если элементы прибывают в отсортированном виде, то спуск всегда будет вы- 
полняться до самого низа одной из ветвей дерева, фактически представляя собой список 
по указателю :19\е. Этот случай характеризуется всеми проблемами быстродействия, 
присущими спискам. Но если элементы поступают в случайном порядке, то подобная 
ситуация маловероятна и дерево будет более-менее сбалансированным. 
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Достаточно сложно реализовать такое дерево, которое гарантированно будет сба- 
лансированным. Это одна из причин, по которой существует так много типов 
деревьев. Для целей нашего изложения мы оставим все эти вопросы в стороне и 
будем полагать, что поступающие данные достаточно стохастичны, чтобы поддер- 
живать сбалансированность дерева. 

Код функции поиска 1оокир похож на іпѕегі: 


/* 1оокир: ищет имя пате в дереве ёгеер */ 
Матеуа1 *1оокир (Мамеуа1 *Етеер, сһаг *пате) 


106 стр; 


1Е (Ехеер == МО) 
геёџоүгп МО; 
стр = зЕхсшр (пате, Егеер->паме); 
1Е (стр == 0) 
гесигп ёгеер; 
е1зе 1Е (спр < 0) 
геёиџгп 1Іоокир (ёгеер->1еЁё, папе); 
е1зе 
гесиогп 1оокир (ёгеер->гідһі, пате); 


} 


Нужно отметить следующее по поводу функций 1оокир и 1пзеке. Во-первых, 
они очень напоминают реализации двоичного поиска, о которых упоминалось в на- 
чале этой главы. Это не случайно, поскольку в них заложена та же идея, что и в дво- 
ичном поиске (“разделяй и властвуй”), откуда происходит и быстродействие лога- 
рифмического порядка. 

Во-вторых, эти функции являются рекурсивными. Если их переписать в итера- 
ционной форме, они станут еще более похожими на алгоритм двоичного поиска. 
Фактически итерационный вариант функции 1оокир можно получить одним изящ- 
ным преобразованием из ее рекурсивной версии. Если элемент не найден, то послед- 
няя операция в 1оокир — это возвращение результата вызова себя самой, т.е. рекур- 
сивный вызов выполняется в конце. Такой вызов легко преобразовать в итерацион- 
ную форму, подставив нужные аргументы и передав управление в начало. Самый 
прямой способ — это воспользоваться оператором добо, но цикл ухћі1е лучше с 
точки зрения стиля: 


/* пг1оокир: нерекурсивный поиск имени папе в дереве Егеер */ 
Матеуа1 *пг1оокир (Машеуа1 *ёгеер, сһаг *папе) 


іп стр; 

ућі1е (Егеер != МО) { 
спр = зЕгстр (пате, ёгеер->папе) ; 
іЁЕ (стр == 0) 


гесигп ёгеер; 
е1зе 1Е (стр < 0) 

Етеер = ёгеер->1еғЁб; 
е1зе 

Сүеер = ігеер->гідһ; 
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хебакп МЛ; 


Как только появляется возможность обхода дерева, дальнейшие операции полу- 
чаются сами собой. Можно воспользоваться некоторыми методами работы со спи- 
сками, например, написать общую функцию перебора узлов с вызовом другой задан- 
ной функции в каждом узле. Однако на этот раз встает вопрос выбора: когда выпол- 
нять операции над узлом и когда обрабатывать остальную часть дерева? Ответ 
зависит от характера данных, представляемых деревом. Если это упорядоченные 
данные наподобие дерева двоичного поиска, то левая половина всегда обходится 
раньше правой. Но иногда упорядоченность данных имеет нетривиальный характер, 
как, например, в фамильном дереве, и порядок обхода дерева зависит от представ- 
ляемых взаимоотношений между узлами. 


Симметричный (т-от4ет) обход имеет место в том случае, когда операция выпол- 
няется после обхода левого поддерева и до обхода правого: 


/* арр1іуіпогӣег: симметричное применение функции Ёп к ёгеер */ 
уоіа арр1у1погхаехг (Матеуа1 *ігеер, 

уоіа (*Еп) (Матеуа1*, уо1а*), уоіа жага) 
{ 


1Е (Ехеер == МО) 
гебигп; 
арр1Іуіпогӣеү (ёгеер->1еЁі, Ёп, ага); 
(*Еп) (Схеер, ага); 
арр1у1покаех (ёгеер->гісһё, Ёп, ага); 


Эта процедура применяется, если узлы необходимо обработать в порядке сорти- 
ровки, например, для вывода их всех по порядку: 


арр1уіпогӣег (ігеер, ргіпіпу "%5: %х\п"); 
Она также обеспечивает рациональный метод сортировки; вставить все элементы 
в дерево, разместить в памяти массив подходящей длины, а затем скопировать узлы 
по порядку в массив симметричным обходом дерева. 
При концевом (розё-от4ег) обходе дерева операция над узлом инициируется толь- 
ко после обхода всех его потомков: 


/* арр1іуроѕіогӣег: концевой обход с вызовом Ёп */ 
уоіа арр1уроѕзіогаег (Мапеуа1і *ігеер, 

уоіа (*#п) (Матеуа1*, уоій*), уоіа жага) 
{ 


1Е (Ехеер == МО) 

гебигп; 
арр1Іуроѕіогаег (їгеер->1еЁё, Ёп, ага); 
арр1іуроѕіогаег (ёгеер->гідһі, Ёп, ага); 
(*Еп) (Схеер, ага); 
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Концевой обход применяется в тех случаях, когда операция над узлом зависит от 
результата аналогичных операций над его потомками. Примеры таких операций — 
это вычисление высоты дерева (равной наибольшей из высот двух поддеревьев плюс 
единица), размещение графического изображения дерева на странице или экране в 
программе построения диаграмм (для этого нужно выделить каждому поддереву 
место в рабочем пространстве и суммировать их), измерение общей емкости дерева. 

Третий способ обхода — прямой (рте-отает) — применяется очень редко, так что 
не будем здесь тратить время на его обсуждение. 

На практике деревья двоичного поиска применяются довольно редко, хотя В-деревья, 
характерные очень интенсивным ветвлением, используются для хранения информации 
на вспомогательных носителях. В повседневной работе программиста часто встречается 
такое применение деревьев, как разложение структуры оператора или выражения. 
Например, следующий оператор можно представить в виде синтаксического дерева: 


01а = (1ом + 6191) / 2; 
Синтаксическое дерево этого оператора показано на рисунке. 
піа / 


я № 
+ 2 
Том В196 


Чтобы проделать вычисления по даному дереву, следует выполнить его концевой 
обход, применяя соответствующие операции в каждом узле. Более подробно синтак- 
сические деревья рассматриваются в главе 9. 


Упражнение 2.11. Сравните быстродействие функций 1оокор и пу1ооКчр. 
Какова разница между рекурсивной и итерационной формами? 


Упражнение 2.12. Напишите функцию сортировки с симметричным обходом. 
Какой порядок по быстродействию имеет данная операция? При каких условиях она 
может работать плохо? Каковы ее характеристики по сравнению с алгоритмом быст- 
рой сортировки и с библиотечными функциями? 


Упражнение 2.13. Придумайте и реализуйте набор тестов для проверки правиль- 
ности функций работы с деревьями, рассмотренных выше. 


2.9. Хэш-таблицы 


Хэш-таблицы — это одно из величайших достижений в науке программирования. 
В них объединены черты массивов, списков и некоторых сложных математических 
методов. В результате получаются эффективные структуры для хранения и обработ- 
ки динамических данных. Типичным применением хэш-таблиц являются таблицы 
символов, устанавливающие ассоциации между некоторыми значениями (данными) 
и элементами динамического набора строк (ключей). Почти в любом компиляторе 
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используется хэш-таблица, хранящая информацию о всех переменных компилируе- 
мой программы. \еБ-браузеры часто используют такие таблицы для учета просмот- 
ренных страниц, а программы связи с Пиегпеё прибегают к хэш-таблицам для кэши- 
рования доменных имен и ГР-адресов. 

Общая идея состоит в том, чтобы передать ключ в специальную хэш-функцию и 
получить хэш-код, значение которого принадлежало бы к ограниченному целочис- 
ленному диапазону, равномерно заполненному такими ключами. Затем полученный 
хэш-код используется для индексирования таблицы, в которой непосредственно 
хранится информация. В языке ]ауа имеется стандартный интерфейс для работы с 
хэш-таблицами. В Си С++ имеется свой стиль их реализации. Обычно с каждым 
хэш-кодом, или ячейкой (Рисёеѓ) таблицы, ассоциируется список элементов, соот- 
ветствующих этому коду, как показано на рисунке. 


ѕзупсар [МНАЗН] хэш-цепочки 
+ о ә МО, 
01, имя 1 имя 2 
ОТ значение 1 значение 2 


О МО 


01, имя 3 


ОО значение 3 


На практике хэш-функция задается заранее, и для массива данных заблаговре- 
менно распределяется необходимый объем памяти (часто даже на этапе компиляции 
программы). Каждый элемент массива представляет собой список, который связы- 
вает элементы с общим хэш-кодом в цепочку. Другими словами, хэш-таблица из 
п элементов является массивом списков, средняя длина которых составляет 
п / (размер массива). Извлечение элемента из таблицы есть операция порядка О(1) 
при условии, что хэш-функция подобрана удачно и списки не слишком разрас- 
таются в длину. 

Поскольку хэш-функция представляет собой массив списков, тип ее элементов 
должен быть тот же, что и у списка: 


суреаеЕ ѕігисё Машеуа1 Машетуа1; 
ЗЕГасСЕ Матеуа1 { 


сһаг *папе; 

іпі уа11е; 

Мате\уа1 *пехі; /* следующий в цепочке */ 
}; 
Матеуа1 *ѕутёар [МНАЗН]; /* таблица символов */ 


Для работы с отдельными цепочками ячеек применяются методы, рассмотренные 
в разделе 2.7. Если подобрана хорошая хэш-функция, то не будет никаких проблем: 
вычисляйте хэш-код, идите в нужную ячейку и перебирайте список, пока не найдете 
требуемый элемент. Ниже приведен код функции поиска и добавления элемента. 
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Если функция находит элемент в хэш-таблице, она возвращает указатель на него. 
Если элемент не найден и при этом установлен флаг создания стеаке, то элемент 
добавляется в таблицу. Копия имени не создается; предполагается, что вызывающая 
функция сама позаботится об этом. 


/* 1оокир: находит имя пате в таблице зушбаю, по необходимости 
добавляя */ 
Матеуа1* 1оокир (сһаг *пате, 1пЕ стеабе, іпі уа1ае) 


іпё В; 
Матеуа1 *ѕут; 


Һ = Һаѕһ (папе); 
Ғог (зум = ѕутбар [6]; зум != МО; зум = ѕутм->пехі) 
1Е (ѕігстр (пате, ѕут->пате) == 0) 
геёиүп ѕут; 
1Е (сгеабе) { 
зум = (Матеуа1 *) ета11ос (з12еоЕ (Матеуа1)); 
зут->паме = пате; /* размещается в другом месте */ 
зут->уа1ае = уа1ае; 
зум->пехЕ = ѕутёар [1]; 
ѕутёар [1] зум; 


} 


тебоги зум; 


} 


Это сочетание поиска и создания нового элемента по мере необходимости широ- 
ко распространено. Если не сочетать эти операции, работа будет дублироваться. 
Придется писать так: 


1Е (1оокир ("пате") 


== М) 
айаіёет (пемтеем (' 


"пате", уа1ае)); 


В этом случае хэш-код вычисляется дважды. 

Каким должен быть размер массива? Общая идея состоит в том, что массив дол- 
жен быть достаточно велик, чтобы цепочка каждого хэш-кода содержала поменьше 
элементов, и операция поиска имела характер О(1). Например, в компиляторе 
таблица может содержать несколько тысяч ячеек, поскольку большой файл исходно- 
го кода обычно содержит несколько тысяч строк, и ожидается, что новые идентифи- 
каторы будут встречаться с примерной частотой по одному на строку. 

Теперь необходимо решить, что же будет вычислять хэш-функция Һаѕһ. Функ- 
ция должна работать по детерминистическому алгоритму, выдавать код достаточно 
быстро и при этом равномерно распределять данные по массиву. В одном из распро- 
страненных алгоритмов хэш-кодирования строк хэш-код строится путем прибавле- 
ния каждого байта строки по очереди к уже накопленному хэш-коду, умноженному 
на некоторый коэффициент. Умножение позволяет распределить биты из нового 
байта по накопленному коду; в конце цикла кодирования получается хорошо пере- 
мешанная “каша” из байтов входных данных. Для строк в кодировке АЗСП эмпири- 
чески выведенное значение коэффициента, используемого при таком хэш-кодиро- 
вании, составляет от 31 до 37. 
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епит { МОБТТРИЬТЕВ = 31; } 
/* Баз: вычисляет хэш-код строки */ 
ирз1ореа іпё Һаѕһ (сһаг *з6хг) 


ирз1ореа 106 Ъ; 
ирз1оареа сһаг *р; 


В 0$ 

Ғог (р = (поз1ореяа саг *) зЕк; *р != '\0'; р++) 
Ъ = МОІТІРІІЕК * В + *р; 

гебагп В % МНАЗН; 


} 


В этой операции явным образом используются символы типа ипз1дпе@Я сћһаг 
(без знака), поскольку стандарт С или С++ не гарантирует наличие или отсутствие 
знака у символьных переменных, а хэш-код должен быть положительным. 

Хэш-функция возвращает остаток от деления накопленного результата на длину 
массива. Если хэш-функция распределяет ключи равномерно, точный размер масси- 
ва не имеет значения. Однако стопроцентную надежность хэш-функции гарантиро- 
вать трудно, и даже наилучшие функции могут столкнуться с проблемами при обра- 
ботке некоторых наборов входных данных. Поэтому рекомендуется сделать размер 
массива равным простому числу и тем самым дополнительно подстраховаться, 
поскольку в этом случае размер массива, коэффициент хэш-кодирования и вероят- 
ные значения данных не будут иметь общего делителя. 

Эксперименты показывают, что для очень широкого круга строк трудно постро- 
ить хэш-функцию, которая бы работала заметно эффективнее, чем приведенная вы- 
ше. Зато очень легко сконструировать такую, которая бы работала хуже. В ранней 
версии ]ауа существовала хэш-функция для кодирования строк, которая работала 
тем эффективнее, чем длиннее была строка. Эта хэш-функция экономила время, 
принимая в расчет только 8 или 9 символов через равномерные интервалы, начиная 
с начала, если кодируемая строка была длиннее 16 символов. К сожалению, хоть эта 
функция и работала быстро, ее плохие статистические показатели сводили на нет все 
преимущества быстродействия. Пропуская фрагменты строки, она игнорировала 
наиболее значимые ее части. Например, имена файлов начинаются с длинных, прак- 
тически одинаковых префиксов — имен каталогов — и отличаются только послед- 
ними несколькими символами ( . јауа или .с1азз). ОКІ-адреса обычно начинают- 
ся с ВЕЕр: //ммм., а заканчиваются .БЕт1, имея тенденцию отличаться только в 
середине. Таким образом, хэш-функция часто принимала во внимание только неиз- 
менную часть строки и в результате строила длинные списки элементов в ячейках, 
снижавшие скорость поиска. Проблема была решена заменой этого алгоритма на 
другой, аналогичный показанному выше (с коэффициентом 37), который принимал 
во внимание все символы строки. 

Хэш-функция, хорошо работающая с данными одного вида (например, коротки- 
ми именами переменных), может оказаться неудачной в работе с другими (такими 
как ОКІ -адреса), поэтому хэш-функцию для своей программы следует тестировать 
на типичных наборах входных данных. Хорошо ли она кодирует короткие строки? 
А длинные? А строки одинаковой длины с небольшими отличиями? 
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Строки — это не единственные объекты, которые можно организовывать в хэш- 
таблицы (хэш-кодировать). Например, в программе физического моделирования и 
расчета можно хэш-кодировать трехмерные координаты частиц, тем самым органи- 
зуя хранилище данных в виде линейной таблицы порядка О(количество частии) 
вместо трехмерного массива порядка О(размерХ х размерУх размер/.). 

Одно из замечательных применений хэш-кодирования можно найти в программе 
Джерарда Хольцмана (СегагА Ноіхтапп) под названием Ѕирегігасе, предназначен- 
ной для анализа протоколов и систем параллельной обработки данных. Программа 
Ѕирегітасе получает на вход полную информацию о всех возможных состояниях 
анализируемой системы и хэширует ее, чтобы получить адрес единственного бита 
памяти. Если этот бит установлен, значит, состояние уже было зарегистрировано 
ранее; если сброшен, то нет. В программе Ѕирегігасе используется хэш-таблица дли- 
ной во много мегабайт, но в каждой ячейке хранится всего один бит. Цепочки 
(списки) данных не создаются; если вдруг два состояния конфликтуют, получая 
один и тот же хэш-код, программа просто игнорирует этот факт. Программа полага- 
ется на низкую вероятность подобного конфликта (эта вероятность не обязана быть 
нулевой, поскольку алгоритм работы Ѕирегігасе носит вероятностный, а не детерми- 
нистический характер). Поэтому хэш-функция в ней написана особенно тщательно, 
с использованием циклического избыточного контроля (сусйс тедипаапсу сйесК), 
который позволяет получить очень равномерную “смесь” исходных данных. 

Хэш-таблицы прекрасно подходят для организации таблиц символов, поскольку 
обеспечивают доступ к любому элементу за время порядка О(1). Ноу них есть и ряд 
недостатков. Если хэш-функция написана плохо или размер таблицы недостаточен, 
то списки в ячейках вырастают до нерациональной длины. Поскольку эти списки не 
отсортированы, время обращения к данным возрастает до О(п). Элементы нельзя 
непосредственно расположить в отсортированном порядке, но можно подсчитать их, 
выделить массив нужной длины, заполнить его указателями на элементы и отсорти- 
ровать их. И все же при правильной организации хэш-таблиц им нет равных среди 
других структур данных по таким показателям, как объем операций, требуемый для 
поиска, вставки и удаления элементов. 


Упражнение 2.14. Наша хэш-функция имеет довольно общий характер и удобна 
при работе со строками. Однако с некоторыми исходными данными она может 
справляться недостаточно эффективно. Сконструируйте набор данных, который бы 
заставил эту функцию работать плохо. Насколько трудно построить такой набор для 
различных значений МНАЅН? 


Упражнение 2.15. Напишите функцию для обращения к последовательным 
элементам хэш-таблицы в несортированном порядке. 


Упражнение 2.16. Модифицируйте функцию 1оокир так, чтобы при превыше- 
нии средней длиной списка некоторого порога х массив расширялся бы автоматиче- 
ски с коэффициентом пропорциональности у и чтобы хэш-таблица подвергалась 
перестройке. 
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Упражнение 2.17. Разработайте хэш-функцию для хранения координат точек в 
двумерном пространстве. Насколько легко адаптировать вашу функцию к измене- 
ниям типа координат (например, от целочисленных к вещественным), системы 
координат (от декартовой к полярной) или размерности (от двух к более высокой)? 


2.10. Резюме 


Алгоритм для решения своей задачи следует выбирать в несколько этапов. 
Вначале проанализируйте потенциально пригодные алгоритмы и структуры данных. 
Оцените, какой объем данных придется обрабатывать программе. Если в задаче уча- 
ствует сравнительно немного данных, ограничьтесь простыми методами; если объем 
данных может возрасти в будущем, отбросьте методы, не приспосабливающиеся к 
увеличению размерности задачи. Затем выберите средство языка или стандартной 
библиотеки для решения поставленной проблемы. Если такового не существует, 
постарайтесь написать (или заимствовать) короткую, простую и легко понятную 
программную реализацию решения. Протестируйте ее. Только если тесты покажут, 
что она работает слишком медленно, следует переходить к более усовершенствован- 
ным методам. 

Хотя существует множество структур данных, и многие из них играют критиче- 
скую роль для быстродействия программ, на практике большинство программных 
систем основано на использовании массивов, списков, деревьев и хэш-таблиц. 
Каждая из этих структур поддерживает определенный набор базовых операций, 
таких как создание нового элемента; поиск, добавление, удаление элемента; приме- 
нение некоторых операций ко всем элементам сразу. 

Каждая из операций имеет свое характерное время выполнения, которое часто 
определяет, насколько хорошо конкретный тип данных (или его реализация) подхо- 
дит для того или иного приложения. Например, массивы предоставляют такой дос- 
туп к своим элементам, время которого не зависит от их количества, но зато неспо- 
собны достаточно гибко расти или уменьшаться в размерах. В списках удобно вы- 
полнять операции добавления и удаления, но для обращения к конкретному 
элементу требуется порядка О(и) операций. Деревья и хэш-таблицы являются ра- 
зумным компромиссом: быстрый доступ к отдельным элементам сочетается с про- 
стыми механизмами расширения, по крайней мере при соблюдении некоторого кри- 
терия сбалансированности. 

Для специализированных задач часто создаются более сложные и изощренные 
структуры данных, но перечисленного набора вполне достаточно для программной 
реализации подавляющего большинства прикладных задач. 


78 Алгоритмы и структуры данных Глава 2 


Дополнительная литература 


Доступное изложение большого количества разнообразных алгоритмов можно 
найти в серии книг: ВоЬ Ѕейвехіск, Аотийтз (АЧЧ1зоп-\езеу). Третье издание 
книги А/соғіїйтѕ т С++ из этой серии (1998 г.) содержит полезный материал по хэш- 
функциям и вопросам объема хэш-таблиц. Надежным источником строго и последо- 
вательно проанализированных алгоритмов является книга Оопа!4 КпибВ, Тйе Ап оў 
Сотриіет Ргортаттіпе (АЧ41зоп-Уез[еу). В 3-м томе этой книги (2-е издание, 1998 г.) 
как раз рассматриваются алгоритмы сортировки и поиска". 

Программа Ѕирегітасе описана в книге Сегагі Ноіхтарп, Оеяют апа Уайаайоп оѓ 
Сотршет Ргоюсоб (Ргеписе На]ї, 1991). 

Построение эффективного и устойчивого алгоритма быстрой сортировки рас- 
сматривается в статье Ј. Вет еу, О. МсПгоу, “Епетеегтя а зотё апсНоп”, бо ате — 
Ргасйсе апа Ехрепепсе, 1993, 23, 1, р. 1249—1265. 


1 Все три книги Дональда Кнута “Искусство программирования” вышли на русском языке в 
ИД “Вильямс” в 2000 году. — Прим. ред. 


Проектирование и реализация 


Покажите мне ваши блок-схемы, спрятав таблицы данных, — и я по-преж- 
нему буду теряться в догадках. Покажите таблицы — и блок-схемы, как 
правило, не понадобятся, поскольку будут очевидны. 


Фредерик П. Брукс-мл. “Мифический человеко-месяц” 
(ЕтейегісЬ Р. ВтооЁз,.]т., Тће Муса! Мап Мопіћ) 


Перефразируя эпиграф, в котором приводится цитата из классической книги 
Ф. Брукса, можно утверждать, что проектирование структур данных является ре- 
шающим элементом при разработке программ. Как только структуры данных окон- 
чательно определены, в алгоритме все обычно становится на свои места и программ- 
ная реализация уже не представляет никакой сложности. 

Конечно, эта точка зрения несколько упрощена, но все же недалека от действи- 
тельности. В предыдущей главе рассматривались основные структуры данных, яв- 
ляющиеся строительным материалом для большинства программ. В этой главе мы 
скомбинируем несколько подобных структур в ходе проектирования и реализации 
небольшой программы. Будет показано, как суть задачи влияет на применяемые 
структуры данных и как последующее написание кода облегчается тщательным вы- 
бором объектов для хранения данных. 

Один из аспектов этой точки зрения состоит в том, что выбор языка программи- 
рования не так уж существен при проектировании программы в целом. Вначале мы 
спроектируем абстрактную реализацию алгоритма, а затем напишем ее на языках С, 
Јауа, С++, Ак и Регі. При сравнении этих реализаций станет ясно, в чем особенно- 
сти конкретных языков помогают и в чем мешают воплощению алгоритма в про- 
грамму, а также в каких аспектах они несущественны. Выбор языка программирова- 
ния придает программе тот или иной колорит, но редко влияет на ее принципиаль- 
ную структуру. 

Выбранная для этой цели задача довольно необычна, но самая общая ее форма 
такая же, как и у других программ: на вход поступают одни данные, на выходе полу- 
чаются другие, и для превращения одних в другие необходимо применить набор 
нетривиальных операций. 

Мы хотим сгенерировать случайный текст на английском языке, который можно 
было бы прочитать. Если генерировать слова или буквы по счетчику случайных чи- 
сел, в результате получается бессмыслица. Например, если программа выдает наугад 
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выбранные буквы (а также пробел для отделения одного слова от другого), то может 
получиться примерно следующее: 


хрЕмхап хиѕаја аЁапгах1 1101а1мса гјајоуруагімпју 


Это мало напоминает текст. Если ассоциировать с буквами весовые коэффициен- 
ты по частоте их употребления в английском языке, то получится нечто вроде этого: 


ійсеҒоае Есз Ехаег јсіі оғаѕ1іпадеёаср Е о1а 


Нельзя сказать, что этот результат чем-то лучше предыдущего. Также не слиш- 
ком осмысленным получается текст, если составить его из слов, наугад выбранных 
из словаря: 


ро1іудасёу1 едоаіогіа1 ѕр1аѕһі1у јом1 уегаһааһ сігситѕ=сгіре 


Для получения более качественных результатов нам необходима более структури- 
рованная статистическая модель, например, распределение частот словосочетаний. 
Но где взять такую статистику? Можно, конечно, взять большой объем английских 
текстов и подробно изучить их, но есть более легкий подход, сочетающий приятное с 
полезным. Ключевое наблюдение состоит в том, что можно взять любой текст и по- 
строить статистическую модель именно этого текста, а затем генерировать на его 
основе случайный текст со статистическими свойствами, подобными оригиналу. 


3.1. Цепь Маркова 


Поставленная задача обработки данных изящно решается с помощью алгоритма, 
в котором используется цепь Маркова. Представим себе входные данные как цепоч- 
ку перекрывающихся словосочетаний. Данный алгоритм делит каждую фразу на две 
части: префикс из нескольких слов и суффикс из одного слова, следующий за 
префиксом. Рассматриваемый алгоритм генерирует фразы на выходе, случайным 
образом выбирая для определенного префикса следующий за ним суффикс. Выбор 
делается на основе статистики — в данном случае статистики исходного текста. 
Для этой цели вполне подходят сочетания из трех слов, т.е. по префиксу из двух слов 
выбирается третье слово-суффикс: 


поместить в ми и) первые два слова текста; 
вывести ими ю; 
цикл: 
случайно выбрать и; из набора суффиксов 
к префиксу ми и; 
заменить ми № на и из; 
повторить цикл; 


Для иллюстрации этого подхода предположим, что необходимо сгенерировать 
случайный текст на основе нескольких адаптированных фраз из оригинального тек- 
ста эпиграфа к данной главе, используя префиксы из двух слов: 


бром уоцг ЁҒ1омсһагёѕ апа сопсеа1 уоцхг сар1еѕ апа І мі11 Бе тузііѓіеа. 
ЅҺом уоцг бар1еѕ апа уоџг #1омсһагіѕ мі11 ре оруіоцѕ. (епа) 
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Вот некоторые пары слов из исходных данных и следующие за ними слова. 


Префиксы из двух слов Слова-суффиксы 
Ѕһом уоиг Помсһагіѕ ёаБеѕ 
уоиг Помсһагіѕ ап мі 
Помсһагіѕ апі сопсеа| 

Помсһагіѕ мі Бе 

уоцг ќаБеѕ апа апі 

міШ Бе туѕіібеа. оБ\!ючз. 
Бе туѕіібеа Ѕһом 

Бе оБуіоциѕ. (епа) 


Марковский алгоритм начинает свою работу по обработке этого текста с вывода 
слов Ѕћом уоп, а затем случайным образом выбирает либо Е1омсвахЕз, либо 
сар1еѕ. Если выбирается первый вариант, то префикс приобретает вид уоџцг 
Е1омсвагкез и следующее слово должно быть апа или мі11. Если выбирается ва- 
риант сар1ез, то следующим словом будет апа. Так продолжается до тех пор, пока 
не будет сгенерировано достаточно текста или пока в качестве суффикса не встре- 
тится маркер (епа). 

Наша программа будет считывать фрагмент английского текста и использовать 
марковский алгоритм для генерирования нового текста на основе частот появления 
словосочетаний фиксированной длины. Количество слов в префиксе, а в нашем при- 
мере их два, будет являться параметром задачи. Чем короче префикс, тем более бес- 
связным оказывается новый текст; чем этот префикс длиннее, тем больше программа 
склонна повторять текст практически дословно. Для англоязычного текста выбор 
третьего слова по двум предыдущим является хорошим компромиссом. Это позволяет 
сохранить колорит исходного текста, добавив к нему новые причудливые штрихи. 

Что такое слово? Очевидный ответ таков: это последовательность букв алфавита. 
Однако желательно оставить в тексте его пунктуацию, поэтому следует считать сло- 
ва “иог@5” и “иог@5.” различными. Таким образом улучшается качество сгенери- 
рованного текста, поскольку в нем сохраняются знаки препинания, а значит, и до 
некоторой степени грамматика. Это обстоятельство также влияет на выбор слов, хо- 
тя часто приводит к незакрытым кавычкам или скобкам и т.п. Поэтому определим 
“слово” как строку символов, выделенную пустым пространством; это определение 
не накладывает никаких ограничений на входной язык и оставляет на месте знаки 
препинания, стоящие после слов. Поскольку в языках программирования обычно 
имеются средства для разделения текста на такие “слова”, этот подход можно легко 
реализовать. 

В силу выбранного метода все отдельные слова, а также словосочетания из двух и 
трех слов, возникающие на выходе программы, уже встречались во входных данных. 
Однако наберется немало заново синтезированных фраз из четырех и более слов. 
Ниже приведено несколько предложений, выданных той программой, которую мы 
еще только собираемся написать в этой главе. Исходным материалом послужила 
глава 7 из книги Э. Хэмингуэя “И восходит солнце”. 
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Аз І збагбе ир һе ип4дегз ге опо 15 сБезё МасК, ара в ѕќотасһ тизез 
Бет ип4ег (ће |126. "Уоц ѕее Һет?" Ве]о\ Һе Ппе мһеге һіѕ гіБѕ ѕёоррей 
мете іо га1зе4 ре ме]—5. "Зее оп ће югереа4." "ОҺ, Вгеѓ, І Іоуе уои." "её 
поё (ак. Та] кіре'ѕ а] Б ве. Г роіпе амау іотоггом." "Тотоггом?" "Уез. рійап'ё 
І ѕау 50? Г ат.” "Гес'ѕ һауе а дгіпк, һер." (Как только я рубашку на его грудь 
черную, и могучие брюшные мышцы вздувавшиеся в свете. "Видите?" Пониже 
того места, где кончались ребра, было два выпуклых белых шрама. "Смотри в 
лоб." "Ах, Брет, я так тебя люблю." "Долой разговоры. Разговоры - чушь. 
Я завтра уезжаю." "Завтра?" "Да. Разве я не говорила? Уезжаю." "Тогда пой- 
дем выпьем.") 


Здесь нам повезло — знаки препинания сохранились. Но так происходит не всегда. 


3.2. Выбор структур данных 


С каким объемом входных данных придется иметь дело? Каким быстродействием 
должна отличаться программа? Кажется разумным, что она должна уметь проанали- 
зировать целую книгу, поэтому следует быть готовыми к чтению около п = 100 000 
слов. На выходе будет сгенерировано несколько сотен или тысяч слов, и программе 
для этого должно понадобиться несколько секунд, а не минут. Имея 100 000 слов 
исходного текста, не следует выбирать слишком примитивный алгоритм, иначе про- 
грамма не будет работать достаточно быстро. 

Используемый марковский алгоритм должен проанализировать все входные 
данные, прежде чем он начнет генерировать что-либо на выходе. Поэтому придется 
хранить сразу весь объем исходных данных в какой-то подходящей для этого форме. 
Один из простейших вариантов — это поместить весь исходный текст в длинную 
строку. Но нам, очевидно, необходимо иметь дело с текстом, разбитым на слова. 
Если сохранить его в виде массива указателей на слова-строки, то генерировать вы- 
ходные данные будет достаточно просто: для вывода одного слова перебираем вход- 
ной текст в поисках суффиксов, следующих за только что сгенерированным префик- 
сом, а затем выбираем один из их числа наугад. Однако это означает, что придется 
перебирать все 100 000 исходных слов для генерирования каждого слова на выходе. 
Если нужно вывести 1000 слов, это будет означать сотни миллионов операций срав- 
нения строк, и о быстродействии придется забыть. 

Следующий вариант — это хранить только неповторяющиеся слова из входных 
данных вместе со списками мест, в которых они встречаются в тексте, чтобы поиск 
следующих за ними слов выполнялся быстрее. Для этого можно было бы воспользо- 
ваться такой таблицей, какая описана в главе 2, но она не вполне подходит для нужд 
нашего алгоритма — быстрого поиска всех суффиксов по заданному префиксу. 

Нам нужна структура данных, которая бы наилучшим образом представляла 
префикс и ассоциированные с ним суффиксы. Программа будет работать в два про- 
хода: на первом проходе будет строиться структура данных, представляющая слово- 
сочетания, а на втором — генерироваться случайный выходной текст. На обоих про- 
ходах необходимо уметь быстро разыскивать любой конкретный префикс: сначала 
для обновления списка его суффиксов, затем для случайного выбора из этого списка. 
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Напрашивается хэш-таблица, в которой префиксы играли бы роль ключей, а значе- 
ния состояли бы из наборов соответствующих им суффиксов. 

Для определенности выберем префикс из двух слов, т.е. каждое слово на выходе 
программы будет определяться парой предшествующих ему слов. Количество слов в 
префиксе не влияет на структуру программы, и программа должна быть способна 
обрабатывать префиксы любой длины; выбор длины просто делает наше изложение 
более конкретным. Назовем совокупность префикса и соответствующего ему набора 
возможных суффиксов состоянием; это стандартный термин в описаниях алгорит- 
мов, основанных на цепях Маркова. 

Имея префикс, необходимо сохранить все его суффиксы, чтобы обращаться к 
ним впоследствии. Суффиксы никак не упорядочены и добавляются по одному за 
раз. Заранее неизвестно, сколько всего их будет в каждом случае, поэтому нужна 
эффективно и быстро расширяемая структура данных, например список или дина- 
мический массив. При генерировании текста необходимо наугад выбирать один 
суффикс из их набора, ассоциированного с данным префиксом. Элементы структу- 
ры исходных данных никогда не удаляются. 

Как быть, если словосочетание встречается несколько раз? Например, словосоче- 
тание “встретиться дважды" может встретиться дважды, а словосочетание 
“только однажды” — только однажды. Эту задачу можно решить, либо помещая 
суффикс “дважды” дважды в список суффиксов, либо помещая его только один раз, 
но придав ему счетчик со значением 2. Мы попробовали и так и этак. Без счетчика 
оказалось летче, поскольку при добавлении суффикса не требуется проверять, есть 
ли он уже в списке, а разница в быстродействии была несущественной. 

Подведем итоги. Каждое состояние включает в себя префикс и список суффик- 
сов. Эта информация помещается в хэш-таблицу, ключами которой служат префик- 
сы. Каждый префикс представляет собой набор слов фиксированной длины. Если 
суффикс встречается в связи с конкретным префиксом несколько раз, каждое его 
вхождение включается в список отдельно. 

Дальше следует принятьрешение, как представлять сами слова. Самый легкий спо- 
соб — это хранить их в виде отдельных строк. Поскольку в большинстве текстов одни и 
те же слова встречаются множество раз, наверное, стоило бы сэкономить место в памя- 
ти, заведя вторую хэш-таблицу отдельных слов, чтобы хранить каждое из них в един- 
ственном экземпляре. Это, вероятно, ускорило бы хэш-кодирование префиксов, по- 
скольку можно было бы сравнивать указатели, а не отдельные символы — уникальные 
строки будут иметь уникальные адреса. Реализацию этого подхода мы оставляем чита- 
телю в качестве упражнения; пока же все слова будут храниться в отдельных строках. 


3.3. Построение структуры данных на С 


Начнем с реализации программы на языке С. Первым делом нужно объявить 
несколько констант. 


епим { 
МРРЕЕ =2, /* количество слов в префиксе */ 
МНАЅН = 4093, /* размер массива состояний */ 
МАХСЕМ = 10000 /* максимальный объем текста на выходе */ 
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В этой декларации объявляются количество слов (МРВЕР) в префиксах, размер 
массива хэш-таблицы (МНАЗН) и верхний предел для количества слов в генерируе- 
мом тексте (МАХСЕМ). Если МРВЕЕ представляет собой константу, определяемую до 
компиляции, а не переменную, то управление данными значительно упрощается. 
Размер массива выбран достаточно большим, поскольку на вход программы предпо- 
лагается подавать большие документы, такие как целые книги. Выбрано значение 
МНАЅН = 4093, поскольку если входные данные содержат 10 000 различных пре- 
фиксов (пар слов), то средняя длина цепочки в хэш-таблице совсем невелика — 
два-три префикса. Чем больше размер, тем короче средняя длина такой цепочки и 
тем быстрее осуществляется поиск в таблице. Наша программа не имеет особого 
практического значения (это просто игрушка), поэтому ее быстродействие не играет 
роли, но если сделать массив слишком коротким, то программа вообще не справится 
с входными данными за сколько-нибудь разумное время. С другой стороны, если 
слишком раздуть размеры массива, он может не поместиться в имеющуюся память. 

Префикс можно хранить в виде массива слов. Элементы хэш-таблицы будут 
иметь структурный тип Ѕбабе, в котором с каждым префиксом ассоциируется спи- 
сок суффиксов (элементов типа 54 ЕЁ1х): 

СуреаеЕ ѕігисі ЗЕабе 5+каЕе; 


суреде? ѕігисі ЗаЕЁ1х ЗаЕЁЕ1х; 
ѕірисі Ѕёаёе { /* префикс + список суффиксов */ 


сһаг *ргеЕ [МРВЕЕ]; /* слова-префиксы */ 
ЗаЕЁ1х *5в1Ё; /* список суффиксов */ 
Ѕёаёе *пехі; /* следующий элемент в таблице */ 


}; 


зЕГиСЕ ЅиЁҒіх { /* список суффиксов */ 


сһаг *иога; /* суффикс */ 

Ѕби##іх *пехі; /* следующий элемент в списке */ 
} 
Зкасе *эсасесар [МНАЗН] ; /* хэш-таблица состояний */ 


Символически можно изобразить эту структуру данных следующим образом: 


ѕбасебар: 


объект Ѕёаёе: 
бих: 
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Необходимо построить хэш-функцию для префиксов, представляющих собой 
массивы строк. Нетрудно модифицировать строковую хэш-функцию из главы 2 для 
перебора всех строк в массиве, таким образом выполняя хэш-кодирование конкате- 
нации (сцепления) строк: 


/* Һаѕһ: вычисляет хэш-код для массива из МРВЕЕ строк */ 
ипѕіспеа іпё Һаѕһ (сһаг *з[МРВЕЕ]); 


{ 


опѕідпеа 110% В; 
ип51апеа сһаг *р; 


106 1; 
ВЕ 0 
Ғор (і = 0; і < МРВЕЕ; 1++) 
Ғог (р = (опѕідпеа сһаг *) 5[1]; *р != '\0'; р++) 


В = МОІТІРІІЕВ * В + *р; 
гебогп В % МНАЅН; 


} 


Выполнив аналогичную модификацию функции поиска по таблице, получаем 
окончательную реализацию требуемой хэш-таблицы: 


/* 1оокир: ищет префикс или создает его по запросу. */ 

/* возвращает указатель на префикс; МОШ в случае неудачи. */ 

/* при создании не вызывается з6х@ир, поэтому строки нельзя 
изменять */ 

Ѕіаёе* 1оокир (сһаг *ргеЕ1х[МРВЕЕ], 116 сгеаке) 


тие, В 
Зсаее зр; 


В = һаѕһ (ргеЕЁ1х); 
Еог (ѕр = збабеваь [1]; ѕр != МО; ѕр = ѕр->пехі) { 
Ғор (і = 0; і < МРВЕЕ; 1++) 


1Е (ѕігстр (ргеҒғіх [1], ѕр->ргеѓ [1]) != 0) 
ргеак; 
1Е (1 == МРВЕЕ) /* префикс найден */ 


геигп 5р; 


1Е (сгеаее) { 


зр = (56абе *) ета11ос ($12еоЕ (Ѕіёаёе)); 
Рог (і = 0; і < МРВЕЕ; 1++) 
зр->ргеЕ[1] = ргеЕ1х[1]; 


зр->51Ё = МО; 
ѕр->пехі = збабеваь [1]; 
ѕСасесар [№] = эр; 


} 


тебагп эр; 


} 


Заметьте, что функция 1оокир не делает копию поступающей строки при созда- 
нии нового состояния; она всего лишь помещает указатель на нее в ѕр->ргеѓ []. 
Функции, из которых вызывается 1оокир, должны сами гарантировать, что строко- 
вая информация не будет впоследствии затерта. Например, если строка находится в 
буфере ввода-вывода, то перед вызовом 1оокир ее необходимо скопировать в ста- 
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ционарное место в памяти, чтобы при последующих операциях ввода не были затер- 
ты данные, на которые уже имеется ссылка в хэш-таблице. В программах часто воз- 
никает необходимость принять решение, какой из модулей будет владеть и распоря- 
жаться тем или иным ресурсом общего пользования. Эта тема будет рассмотрена 
более подробно в следующей главе. 

Далее необходимо построить хэш-таблицу по мере считывания файла исходных 
данных: 


/* рџиі1а: считывает входные данные, строит таблицу префиксов */ 
уоіа Ра11а(свах *ргеЁіх [МРВЕЕР], РТЬЕ *#) 


срах БаЕЁ[100], Ёт [10]; 


/* строится строка формата; %ѕ затерла бы буфер */ 
зру1пЕЕ (Ёп, "%%%а5", ѕігеоѓЁ (раЕЁ) -1); 
мһі1е (ЕзсапЕЁ (Ё, Ёт, БаЕЁ) != ЕОЕ) 

ааа (ргеғіх, еѕігаир (ри#)); 


} 


Интересный вызов функции ѕргіпе# призван обойти известную проблему с 
функцией ЕзсапЕ, которая в других случаях идеально подходит для такой работы. 
Вызов ЕзсапЕ со спецификацией формата %5 приводит к считыванию следующего 
слова (строки, окруженной пробелами) из файла в буфер, но при этом никак не 
ограничивается длина слова. Слишком длинное слово может переполнить буфер 
ввода, и последствия будут непредсказуемыми. Если объявить буфер длиной 100 
символов (а это намного больше, чем длина слова в любом английском тексте), то 
можно воспользоваться спецификацией %995, оставив один байт для завершающего 
нуля ('\0'). В этом случае функция ЕзсапЕ прекращает ввод не позже чем через 
99 символов. Длинное слово может оказаться разбитым на части, что неудобно, 
однако совершенно безопасно. Можно было бы объявить так: 


? епим { ВОРЗТОЕ = 100 }; 
? сһаг Ето [] = "$9959"; /* ВОЕЅІ7Е - 1 */ 


Но в этом случае одной ключевой величине — размеру буфера — соответствуют 
сразу две объявленные переменные, и при этом возникает необходимость следить за 
их соответствием друг другу. Задача решается раз и навсегда введением динамиче- 
ской строки формата, которая строится по ходу функции с помощью вызова 
ѕргіпе#. Именно этот подход мы и применили. 

Функция Ьці1а принимает два аргумента: массив рхеЕ1х, содержащий преды- 
дущие МРВЕЕ слов из входного файла, и указатель типа ЕТЬЕ. В свою очередь, она 
передает в функцию ада массив ргеѓіх и копию поступившего на вход слова. 
Функция ааа добавляет новый элемент в хэш-таблицу и передвигает префикс на 
одну позицию вперед: 


/* ааа: пополняет список суффиксов, обновляет префикс */ 
уоіа ааа (сһаг *ргеғіх [МРВЕЕ], сһаг *зцЕЁЕ1х) 


Ѕіаёе *5р; 


зр = Іоокир (ргеѓЁіх, 1); /* создаем, если не нашли */ 
ааазаЕЕ1х (ѕр, ѕиЁѓіх); 
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/* сдвиг слов в префиксе */ 
петшоуе (рхеЁ1х, ргхеЁ1х+1, (МРКЕР-1) *512е0Е (рхеЕ1х [0])); 
ргеЁіх [МРВЕЕ-1] = заЕЁЕ1Х; 


Вызов функции теттоуе — это стандартная конструкция для удаления 
элементов из массива. При этом элементы с номерами от 1 до МРВЕЕ-1 в префиксе 
сдвигаются в позиции от 0 до МРКЕЕ-2 соответственно, тем самым удаляя первое 
слово префикса и освобождая последнюю позицию для нового слова. 

Функция ааа с Е Ех добавляет новый суффикс в список: 

/* ааазоЕЕ1х: добавляет суффикс к состоянию; суффикс изменять 


нельзя */ 
уоіа ааазоЕЕ1х (Ѕёасе *5р, сһаг *заЕЁ1х) 


биЁЁҒіх *50Ё; 


заЕ = (ЅиғғҒіх *) епа110ос (ѕ5і2еоғЁ (ЅиЁЁіх)); 
Б5ЦЁ->мора = заЕЁЕ1х; 
БОЁ->пехії = эр->51ЕЁ; 

зр->51Е = зиЁ; 

Итак, операция обновления состояния разнесена по двум функциям: функция 
ааа выполняет подготовительную работу по добавлению суффикса к префиксу, 
тогда как функция ааазаЕЕ1х выполняет специфическую проблемно-ориентиро- 
ванную операцию по добавлению слова к списку суффиксов. Функция ааа исполь- 
зуется в функции рџоі1а, а вот ааазаЕЕ1х вызывается только из ааа. Таким обра- 
зом, ааазаЕЕ1х относится к числу низкоуровневых подробностей реализации, 
которые могут со временем измениться. Именно поэтому лучше иметь для этой цели 
отдельную функцию, пусть даже она и вызывается всего в одном месте. 


3.4. Генерирование выходных данных 


Разработав структуру данных, принимаемся за генерирование текста. Основная 
идея не изменилась: имея префикс, наугад выбираем один из суффиксов, выводим 
его и передвигаем префикс по тексту. Это стационарное состояние алгоритма, одна- 
ко необходимо еще решить, с чего начинать и чем заканчивать его работу. Начать 
работу легко, если вначале запомнить слова самого первого префикса. Закончить 
тоже нетрудно — для этого нужно всего лишь иметь завершающее слово, маркер 
конца текста. После всех слов исходного текста можно поставить “слово”, которое 
гарантированно не может появиться ни в одном тексте: 


ро11а(рхеЁ1х, ѕёаіп); 
ааа (ргеЁ1х, МОММОЮО); 


Строка МОМИОРР” должна содержать нечто такое, чего не бывает в обычном тексте 
на английском языке. Поскольку слова отделяются друг от друга во входном потоке 


символами свободного пространства, один из таких символов подойдет в качестве 
маркера конца. Это может быть символ конца строки: 


сһаг МОММОКЮО [] = "\п"; /* не бывает словом */ 
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Еще одна потенциальная проблема: а что если текста на входе недостаточно, что- 
бы начать работу алгоритма? Имеются два подхода к проблемам подобного рода 
либо завершить работу при недостатке исходных данных, либо сделать так, чтобы их 
заведомо было достаточно, и не заниматься проверкой этого факта. Второй подход 
вполне применим к нашей задаче. 

Построение таблицы и генерирование текста можно начать с искусственно по- 
строенного префикса, тем самым гарантируя наличие данных для старта алгоритма. 
Для нулевой итерации цикла заполним префикс строками МОМИОВО и получим то 
дополнительное преимущество, что первое слово входного файла будет уже являть- 
ся суффиксом фиктивного префикса, так что цикл генерации текста должен будет 
выводить только суффиксы без единого префикса. 

Чтобы не получить слишком длинного текста на выходе, можно завершить рабо- 
ту алгоритма либо по достижении заданного количества слов, либо при появлении 
маркера МОММОРР” во входном потоке. Которое из событий произойдет раньше, то и 
будет критерием окончания алгоритма. 

Добавление нескольких строк МОМИОРР” в конец исходных данных существенно 
упрощает основные рабочие циклы программы. Это пример техники программиро- 
вания, состоящей в добавлении символов-разделителей к исходным данным для обо- 
значения их границ 

По возможности следует стараться обработать все нестандартные или исключи- 
тельные ситуации, а также особые входные данные. Код должен быть написан как 
можно проще и строже, чтобы корректно реагировать на любые возможные эксцессы. 

Функция депегабе реализует тот алгоритм, набросок которого был дан вначале. 
В нем генерируется одно слово на каждую выходную строку; затем с помощью тек- 
стового редактора можно собрать эти слова в более длинные строки. В главе 9 
демонстрируется несложная процедура форматирования под названием Ете, вполне 
пригодная для этой цели. 

Если в начале и в конце данных используются маркеры МОММОРРО, функция 
депегаке запускается и завершается вполне корректно: 


/* депегаёе: генерирует текст по одному слову в строке */ 
К депегаіе (іпі пмогаз) 

Ѕіасе *5р; 

биЁҒіх *50Ё; 

сһаг *ргеғіх [МРВЕР], *м; 

106 1, птаёсһ; 


Бог (і = 0; і < МРВЕЕ; і++) /* переустановка префиксов */ 
ргеЁ1х[1] = МОММОЮО; 


Ғор (і = 0; і < пмогав; і++) { 
5р = 1Іоокир(ргеѓіх, 0); 
птасһ = 0; 


Ғор (59Ё = ѕр->5ѕиЁ; ѕиЁ != МОШ; заЁ = заЕ->пехё) 
1Е (гапа() % ++птаёсһ == 0) /* ргор = 1/птаїсћһ */ 
М = заЕ->мога; 
1Е (зе устр (м, МОММОРр) == 0) 
ргеак; 


ргіпіЁ ("%5\п", м); 
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пептоуе (рхеЁ1х, рхеЁ1х+1, (МРВЕЕ-1)*в12еоЕ (рхеЁ1х[0])); 
ргеЁіх [МРВЕЕ-1] = м; 


} 


Обратите внимание на алгоритм выбора одного из элементов наугад в условиях, 
когда неизвестно их общее количество. В переменной птаёсћ подсчитывается коли- 
чество совпадений по мере прохождения списка. В следующем выражении перемен- 
ная птаёсћ инкрементируется, а само выражение является истинным с вероятно- 
стью 1/птабсИ: 


гапа() % ++птасһ == 0 


Таким образом, первый совпадающий элемент выбирается с вероятностью 1, вто- 
рой заменит его с вероятностью 1/2, третий встанет на его место с вероятностью 1/3 
и тд. На любом шаге алгоритма каждый из Ё уже перебранных элементов был вы- 
бран с вероятностью 1/2. 

Вначале в массив ргеҒіх заносятся фиксированные начальные значения, что га- 
рантирует инициализацию хэш-таблицы. Первые найденные значения типа За ЕЕ1х 
будут представлять собой первые слова текстового документа, поскольку только они 
следуют за начальным пустым префиксом. После этого суффиксы станут появлять- 
ся на выходе в случайном порядке. В цикле вызывается функция 1оокир, 
разыскивающая в хэш-таблице соответствующие суффиксы для текущего префикса, 
затем из этих суффиксов случайным образом выбирается один, он выводится в 
выходной поток, и префикс сдвигается на слово вперед по тексту. 

Если выбранный суффикс представляет собой строку МОМИОРР, то работа окон- 
чена, поскольку мы пришли к состоянию конца входного потока. Если суффикс не 
является строкой МОММОВР, то выводим его, отбрасываем первое слово префикса 
вызовом функции тептоуе, назначаем суффикс последним словом префикса и 
переходим к началу цикла. 

Теперь соберем все наши наработки в единое целое с помощью функции таіп, 
считывающей данные из стандартного потока ввода и генерирующей не более 
заданного количества слов: 

/* пагкоу таіп: генератор случайного текста по марковскому 


алгоритму */ 
іп таіп (уоіа) 


106 1, пмогаз = МАХСЕМ; 
сһаг *ркеЁ1х[МРЕВЕ]; /* текущие префиксы */ 


Ғор (і = 0; і < МРЕВЕ; 1++) /* инициализация префиксов */ 
рхеЁ1х[1] = МОММОВО; 

риі1а(рге#іх, ѕіаіп); 

ааа (рге#іх, МОММОЮО); 

депегаѓе (пмогаз); 

геіцгп 0; 


} 


На этом наша С-реализация алгоритма закончена. В конце этой главы мы еще 
вернемся к ней, сравнивая работу программ на разных языках. Величайшие пре- 
имущества С состоят в том, что программист имеет полный контроль над реализаци- 
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ей алгоритма и получающиеся программы, как правило, работают очень быстро. 
Но платить за это приходится изрядным объемом дополнительной работы по рас- 
пределению и освобождению памяти, явному созданию хэш-таблиц и связанных 
списков и т.п. Язык С — это остро отточенный инструмент, которым можно изваять 
элегантное произведение искусства, но можно и накромсать бесформенное месиво. 


Упражнение 3.1. Алгоритм для выбора случайного элемента из списка неизвест- 
ной длины полагается на функцию-генератор случайных чисел, от качества работы 
которого зависит весь алгоритм. Продумайте и проведите эксперимент по анализу 
того, насколько хорошо этот метод работает на практике. 


Упражнение 3.2. Если каждое слово из входного потока помещать во вторую 
хэш-таблицу, то весь текст будет храниться без дублирования и таким образом будет 
сэкономлено место в памяти. Проведите эксперименты с несколькими документами, 
чтобы оценить, насколько велика эта экономия. При такой организации данных в 
хэш-цепочках префиксов можно сравнивать указатели, а не строки, и быстродейст- 
вие должно увеличиться. Реализуйте эту версию программы и оцените разницу как в 
быстродействии, так и в потреблении памяти. 


Упражнение 3.3. Удалите операторы, помещающие разделительные строки 
МОМИОВр в начале и в конце входных данных, а затем модифицируйте функцию 
депегаее так, чтобы она стартовала и завершалась корректно без них. Убедитесь, 
что программа правильно генерирует текст на основе исходных данных из 0, 1, 2, Зи 
4 слов. Сравните эту версию с той, в которой используются строки-разделители. 


3.5. Јама 


Для второй реализации марковского алгоритма будет использоваться язык Јаха. 
Объектно-ориентированные языки наподобие ]ауа стимулируют программиста тща- 
тельно продумывать способы взаимодействия (интерфейсы) компонентов програм- 
мы. Такие компоненты инкапсулируются в самостоятельные группировки данных, 
известные под названием объектов или классов, а с ними ассоциируются функции, 
именуемые методами. 

В языке ]ауа имеется более богатая библиотека, чем в С, в том числе набор 
классов-контейнеров для группировки элементарных объектов разными способами. 
Один из примеров — это класс Уесеох, который реализует динамически растущий 
массив и способен хранить объекты любого производного от Орјесє типа. Есть так- 
же класс Наѕћсар1е, в котором можно хранить объекты одного типа, извлекая их по 
ключам — объектам другого типа. 

В нашей задаче префиксы и суффиксы вполне естественно хранить в объектах 
Уескохг, составленных из префиксов и суффиксов. Можно воспользоваться хэш- 
таблицей типа Наѕћсар1е, содержащей префиксы в качестве ключей и векторы 
суффиксов в качестве значений. Для конструкции такого типа существует термин 
таблица соответствий — в данном случае соответствий между префиксами и суф- 
фиксами. В ]ауа нам не придется организовывать явный тип Ѕбаёе для состояния, 
поскольку в объекте Наѕћбар1е префиксы и суффиксы уже связаны неявным обра- 
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зом (т.е. между ними установлено соответствие). Все это сильно отличается от реа- 
лизации на С, в которой организовывались структуры 5% аке, содержащие префик- 
сы и списки суффиксов, а затем по префиксу строился хэш-код для получения пол- 
ного состояния (Ѕбаѓе). 

Класс Наѕһсар1е содержит метод риє для помещения в таблицу пары 
“ключ-значение”, а также метод деї для извлечения значения по ключу: 


Назреаф1е Һ = пем НазреаЪ1е(); 
Һ.риє (кеу, уа1ое); 
бомебуре у = (бощебуре) Һһ.деї (Кеу) ; 


Наша реализация включает три класса. Первый класс, РхеЁ1х, содержит слова 
префикса: 


с1азз Рүеѓіх { 
рорііс Уесіог ркеЁ; // МРВЕЕ соседних слов из входного потока 


Второй класс, Сһаіп, считывает входные данные, строит хэш-таблицу и генери- 
рует текст. Вот его переменные-члены: 


с1азз Сһаіп { 
ѕбасіс Ғіпа1 іп МРКЕЕ = 2; // длина префикса 
ѕбаёіс Ё1па1 Ѕігіпд МОММОВО = “"\п"; 
// фиктивное "слово", которого нет в тексте 
Наѕһёар1іе ѕёаёебар = пем НазрЕаЪ1е(); 
// ключ - префикс, значение - вектор суффиксов 
РгеЕ1х ргеҒіх = пем РкеЕ1х(МРВЕЕ, МОММОРВр); 
// начальный префикс 
Капаот гапа = пем Вапдот(); 


Третий класс представляет собой открытый интерфейс, который содержит функ- 
цию таіп и создает экземпляр класса СҺаіп: 
с1азз Магкоу { 


зсаё1с Ё1па1 іп МАХСЕМ = 10000; // максимум слов на выходе 
рочр1іс з6аб1с уоіа таіп (Ѕёгіпо[] ахга5) Еркомз ТОЕхсере1оп 


{ 


СҺаіп сһаіп = пем Сһаіп(); 
іпё пмогаѕ = МАХСЕМ; 


сһаіп.риі1а (ѕуѕбет.іп) ; 
сһаіп.депегаїе (пмогаз); 


} 


При создании экземпляра класса Сһаіп он, в свою очередь, создает хэш-таблицу 
и помещает в нее начальные префиксы в виде МРВЕЕ элементов МОМИОЋР. Функция 
Ба11а вызывает библиотечную функцию ЅегеатТокепігег для разбора входного 
потока на отдельные слова, разделенные пустым пространством. Три вызова перед 
началом цикла переводят лексический анализатор в нужное состояние согласно на- 
шему определению “слова”. 
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// Сһаіп.риі1а: строит из входного потока таблицу Ѕ&аѓёе 
уоіа Ра11а (Іприёѕігеат іп) ЕВкомз ІОЕхсерііоп 


ЗЕгеащТокКеп12ег ѕі = пем ЅігеапТокепізег (іп) ; 


ѕі.геѕебѕупёах(); // отмена стандартных правил 

5С .могасһҺагѕ (0, Сһагасіег.мАХ УАЈЕ); // вкл. все символы 

зі .мһіёеѕрасеСһагѕ (0, ' !); // кроме пробела и т.п. 
мһі1е (5Е.пехЕТокеп() != зі.ТТ ЕОЕ) 


ааа (5+ .ѕуа1) ; 
ааа (момиовр) ; 


} 


Функция ааа извлекает вектор суффиксов, соответствующий текущему префик- 
су, из хэш-таблицы. Если таковых нет (вектор пуст), функция ааа создает новый 
вектор и новый префикс для помещения в таблицу. В любом случае к вектору 
суффиксов добавляется новое слово, а затем префикс передвигается вперед путем 
отбрасывания первого слова и добавления нового в его конец. 


// СһҺаіп.ааа: добавляет слово в список суффиксов префикса 
уоіа ааа(5Ет1па мога) 


Уесіог зиаЕ = (Уесіог) ѕёбаёсеѓар.деї (ргеҒіх); 
ТЕ (вы == пи11) { 

зиЁ = пем Месіог (); 

ѕёаѓеёар.риї (пем РхеЕ1х(ргеЁ1х), ѕиғ); 


ѕиЁ .аааЕ1етепі (мога) ; 
ргеЁ1х.ргеЕЁ . гетоуеЕ1 етепіА (0); 
ргеЁ1х.ргеЕЁ .аааЕ1ещепе (мога); 


Заметьте, что если объект ѕи# — нулевой, то функция ааа помещает в хэш- 
таблицу новый объект РхеЕ1х, а не сам ргеѓіх. Это необходимо по той причине, 
что в хэш-таблицах типа НазбеаЪ1е элементы хранятся по ссылке, а не по значе- 
нию, так что если не сделать копию, можно затереть предыдущие данные таблицы. 
С этим обстоятельством мы уже сталкивались при реализации алгоритма на языке С. 

Функция генерирования текста аналогична С-версии, но несколько компактнее, 
поскольку прямой доступ к элементам вектора быстрее, чем последовательный 
перебор списка. 


// Сва1п.чепекаее: генерирование текста на выходе 
а депегабе (іпі пмогазѕ) 
ргеЁіх = пем РгеЁіх (МРВКЕЕ, МОМИОВр); 
Еог (іпё і = 0; і < пмогав; і++) { 
Уесіог ѕ = (Уесіог) ѕіаёсеіар.деї (ргеҒіх); 
іпі г = Маїһ.арѕ (гапа.пехіїпї ()) % 5.512е(); 
Ѕігіп9 ѕиЁ = (56:1па) ѕ.еІетепіАі (г); 
1Е (50#.едџоа15 (МОМИОЮО) ) 
ргеак; 
Ѕуѕіет. оці .ргіпё1іпр (ѕиё); 
ргеЕ1х.ркеЕ . гетоуеЕ1етепѓАї (0); 
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ргеЁ1х.ргеЁ .аЯаЕ1етепе (ѕи#) ; 


} 


Два конструктора класса РкеЁ1х создают два экземпляра на основе исходных 
данных. Первый из них копирует существующий объект РгеЁіх, а второй создает 
префикс из п копий строки; именно второй конструктор используется для создания 
МРЕРЕ копий строки МОММОВР при инициализации: 


// Конструктор РгеЁіх: копирует существующий префикс 
РгеҒіх(Ргеѓіх р) 


{ 


ргеЁЕ = (Месіог) р.ргеЁ.с1опе(); 


// Конструктор РгеЁ1х: создает п копий вех 
РгеЕ1х (іп п, 5Ех1па ѕіү) 


{ 
ргеЁ = пем Уесіог(); 
ок (ПЕ 2 = 0: зп 1) 
ргеЁ.аааЕ1етепе (зі); 


} 


В классе РхеЕ1х есть еще два метода, паѕһСоде и еаца1з, вызываемые неявно 
из реализации класса Наѕћсар1е для индексирования и поиска в таблице. Именно 
необходимость иметь класс с реализацией этих двух методов для корректной работы 
объекта Наѕћёар1е заставила нас сделать РкеЁ1х полноценным самостоятельным 
классом, а не просто объектом Уескох, как суффиксы. 

Метод ВазБСо@е строит единый хэш-код, объединяя набор хэш-кодов для 
элементов вектора: 


ѕёасіс Ғіпа1 іпі МОІТІРІІЕВ = 31; // для ПВазрСоае () 


// Ртеғіх.ҺаѕһСойе: генерирует хэш-код из всех слов префикса 
рур11с 116 ҺаѕһсСоае () 


{ 


106 В = 0; 
Ғог (1106 і = 0; і < ргеЁ.ѕіғе(); 1++) 

В = МОТІРІІЕК * В + ргеЕЁ.е1етепе АЕ (і) .ҺаѕҺСоде (); 
гесигп п; 


} 


Метод едиа1ѕ выполняет поэлементное сравнение слов в двух префиксах: 


// РхеЕ1х.еаца1$: сравнение двух префиксов 
рор1іс Боо1еап еаца1$ (Орјесі о) 


{ 


РгеЕ1х р = (РгеЕ1х) о; 


Ғог (1106 і = 0; і < ргеЁ.ѕіғе(); 1++) 
1Е (!ргеѓ#.е1етепіёА (і) .е4ца1$ (р.ргеЁ .еї1етепіАЁ (і))) 
геёоцгп Ға1ѕе; 
геёигп Ёёгиое; 
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Программа на Јауа существенно короче, чем на С, поскольку в ней многие опера- 
ции выполняются автоматически стандартными средствами. Очевидными примера- 
ми могут служить классы Уесіог и Наѕћсар1е. В целом управление памятью уст- 
роено несложно, потому что векторы растут по мере необходимости, а сборщик 
мусора заботится об освобождении и возвращении в систему той памяти, к которой 
больше не обращаются. Но для корректного использования класса Наѕћсар1е 
необходимо написать функции ҺаѕћСоде и еаца1, поэтому нельзя так уж одно- 
значно сказать, что Јауа заботится обо всех деталях реализации. 

Сравнивая представление и способы работы с одной и той же абстрактной струк- 
турой данных в С и Јауа, сразу можно заметить, что в Јауа обеспечивается лучшее 
разделение функций. Например, перейти от объектов Уескох к массивам было бы 
совсем просто. В С-версии каждый модуль “знает”, что делают все остальные: хэш- 
таблица работает с массивами, которые хранятся в другом месте, функции 1оокир 
известно устройство структур Ѕсасе и баЕЕ1х, и длина массива префиксов также 
является всеобщим достоянием. 

Ниже приведена командная строка для выполнения программы с одним из 
текстовых файлов: 


јауа Магкоу <јг сһетіѕёгу.ёхі | Ётё 


А вот результат работы: 


Мазь ёһе р1аскроага. Маёсһ 16 агу. Тһе маіег доеѕ 

іпёо ЕБе а1к. Мһеп мабехг доеѕ іпіо ЕБе аіг 1% 

еуарогаёеѕ. Тіе а атр с1оёһ ёо опе епа оЕЁ а ѕо1іа ог 1іачіа. 
Іоок агоџпа. Иһаё аге һе ѕо1іа ёһіпдѕ? 

Сһетіса1 сһапдеѕ ёаке р1асе мһеп ѕотеёһіпа Ыцгпѕ. ІЁ 

све Рагп1па табег1а1 Ваз 1144145, ёһеу аге ѕёар1е апа 

све ѕропде гіѕе. ТЕ 1оокеа 1іке аочав, Бабе іі 15 

рогпіпа. Вкеак ир ёһе 1атр оЁ вадахг іпёо ѕта11 ріесеѕ 

апа риё ёһет ёодеёһег адаіп іп ёһе робот оЁ а 1іачоіа. 

(Вымойте доску. Посмотрите ее досуха. Вода поднимается в воздух. 
Когда вода поднимается в воздух, она испаряется. Привяжите мокрую 
ткань к одному концу твердого тела или жидкости. Оглянитесь 
вокруг. Что такое твердые тела? Когда что-то горит, происходят 
химические изменения. Если горящий материал содержит жидкости, 
они устойчивы и губка повышаются. Это было похоже на тесто, но 
оно горит. Расколите кусок сахара на мелкие кусочки и снова 
соберите их у дна жидкости.) 


Упражнение 3.4. Измените Јауа-версию марковского алгоритма так, чтобы 
для хранения префиксов в классе 5каке использовался массив, а не объект Уеског. 


3.6. С++ 


Третью реализацию того же алгоритма мы напишем на С++. Поскольку С++ 
практически представляет собой надмножество С, писать на нем можно так же, как и 
на С, с некоторыми дополнительными удобствами. Первая версия программы 
тагкоу на языке С одновременно является и программой на С++. И все же для С++ 
более характерно определение классов для объектов, используемых в программе, и 
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очень похоже на то, как это делалось в Јауа. Таким образом можно скрыть подробно- 
сти реализации. Мы решили зайти еще дальше и воспользоваться стандартной биб- 
лиотекой шаблонов (Збапдаг4 Тетр]ае Г1Бгагу), или ЅТІ., поскольку в этой библио- 
теке имеются встроенные механизмы, делающие многое из того, что нам нужно. 
Стандарт 180 языка С++ рассматривает ЭТТ. как часть определения языка. 

Библиотека ЅТІ. содержит такие контейнеры, как векторы, списки и множества, 
атакже семейство фундаментальных алгоритмов для поиска, сортировки, добавле- 
ния и удаления элементов. С использованием средств работы с шаблонами в языке 
С++ все алгоритмы ЅТІ. могут применяться к самым разным контейнерам, в том 
числе к нестандартным структурным типам или элементарным встроенным, наподо- 
бие целочисленного. Контейнеры определяются в форме шаблонов С++, экземпля- 
ры которых создаются в нужное время для того или иного типа помещаемых дан- 
ных. Например, имеется шаблон контейнера уесбсог, из которого можно образовы- 
вать конкретные типы наподобие уесёог<іпі> или уесбог<ѕёгіпа»>. Все опера- 
ции над шаблоном уесеог, в том числе стандартные алгоритмы сортировки, 
доступны для работы с вновь определенными типами данных. 

Кроме контейнера уесбсог, напоминающего тип Уесёог из Јауа, библиотека ЭТГ, 
содержит еще и контейнер аеаче. Этот тип данных (его название произносится как 
“дек” и происходит от “аоиЫе-епдеа дцеце”) представляет собой двустороннюю оче- 
редь, выполняющую такие операции, какие мы проделывали с префиксами: содер- 
жит МРКЕЕ элементов, позволяет извлекать первый элемент из начала и добавлять 
новый в конец, и время обеих операций составляет О(1). Тип деачое из библиотеки 
ТГ, имеет несколько более общий характер, чем необходимо, поскольку позволяет 
извлекать и помещать данные с обоих концов, но гарантия его быстродействия дает 
нам основание решительно высказаться в его пользу. 

В ЅТІ. имеется также контейнер тар, базирующийся на использовании сбаланси- 
рованных деревьев и содержащий пары “ключ-значение”. Элементы, ассоциирован- 
ные с теми или иными ключами, извлекаются из него за время порядка О(]о5 п). Эти 
таблицы соответствий могут работать не так быстро, как таблицы с порядком быст- 
родействия О(1), но зато привлекают перспективой вообще не дописывать никакого 
кода. (В некоторых нестандартных библиотеках С++ имеются контейнеры һаѕһ или 
Һаѕһ тар сеще более высоким быстродействием.) 

Мы также пользуемся встроенными функциями сравнения, которые в данном 
случае сравнивают отдельные строки в префиксах. 

Имея под рукой все перечисленные компоненты, из них уже легко собрать нуж- 
ную программу. Вот необходимые объявления: 


СуреаеЕ деацџе<ѕігіпд> РгеЁіх; 
пар<РхеЁ1х, уесіог<ѕігіпд> > ѕёаёсеёар; // префикс -> суффиксы 


В библиотеке ЅТІ. имеется шаблон для двусторонних очередей; употребление его в 
виде дедое<ѕегіпа»> создает очередь со строковыми элементами. Поскольку этот тип 
фигурирует в программе несколько раз, мы дали ему имя РгеЁіх с помощью операто- 
ра суредеЕ. Однако таблица соответствий, в которой хранятся префиксы и суффик- 
сы, встречается всего один раз, так что давать ее типу отдельное имя было незачем. 
Объявляется переменная ѕбабебар типа тар, представляющая собой таблицу соот- 
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ветствий между префиксами и векторами строк. Это удобнее, чем в С и Јауа, поскольку 
не нужно дополнительно писать ни функции паз, ни метод еатла] з. 

Главный модуль программы инициализирует префикс, считывает входные дан- 
ные (из стандартного потока ввода, носящего имя сіп в библиотеке 1озехеам язы- 
ка С++), добавляет “хвост” и генерирует текст таким же образом, как и в предыду- 
щих версиях. 


// Главный модуль: генерирует случайный текст 
іп таіп (уоіа) 


іпі пмог@з = МАХСЕМ; 
РгеЕ1х ргеѓЁіх; // текущий префикс 


Ғор (іп і = 0; і < МРВЕЕ; і++) // инициализация префиксов 
ада (рге#іх, МОоММОрРр); 

риі1а (ргеЁіх, сіп); 

ада (ргеғіх, МОММОВр) ; 

сепегаіе (пмогазѕ) ; 

геёогп 0; 


В функции Ба11а с помощью средств библиотеки іоѕёгеат входной поток 
считывается слово за словом: 


// Ьа11а: считывает данные, строит таблицу состояний 
уоіа риоі1а (РгеҒіх& ргеҒіх, іѕёгеат& іп) 


ѕзігіпа РЕ; 


мһі1е (іп >> риё) 
ада (ргеҒіх, Ыи#); 


} 


Строка Ьџ# расширяется по мере необходимости для работы с поступающими 
на вход словами произвольной длины. 

Функция ааа демонстрирует дополнительные преимущества работы с библиоте- 
кой ЅТІ: 


// ааа: добавляет слово в список суффиксов, обновляет префикс 
уоіа ааа(РгеЕ1х& рхеЁЕ1х, сопзі зЕг1па& в) 


{ 
1Е (рхеЁЕ1х.з12е() == МРВЕЕ) { 
зЕасегар [ргеЁ1х] .риѕћһ Браск (8); 
ргеЕ1х.рор_Ехкопе (); 


ргеЕ1х.ризн баск (з); 


} 


За этими внешне простыми операторами скрывается огромный объем проделы- 
ваемой работы. Контейнер тар перегружает операцию обращения по индексу 
(знак [] ) так, чтобы она выполнялась как операция поиска по таблице. Выражение 
ѕгасебар [ргеғҒіх] служит для выполнения поиска в таблице ѕзёабебар по ключу 
рхеЕ1х; оно возвращает ссылку на требуемую позицию. Если вектор не существует, 
он создается. Функции-методы с именем риѕћ раск классов уесіог и десие 
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помещают новую строку в конец вектора или очереди; метод рор Е гопі извлекает 
первый элемент из очереди. 
Генерирование текста выполняется аналогично предыдущим версиям: 


// депегаёе: вывод текста по одному слову в строке 
уоіа депегабе (іпё пмогаз) 


РгеҒіх рүгеѓіх; 
106 і; 


Ғор (і = 0; і < МРВЕЕ; і++) // инициализация 
ада (рхеЁ1х, МОМИОВр); 


Ғор (і = 0; 1 < пмогав; і++) { 
уесіог<ѕёгіпд>& ѕЅИЁ = зѕіасебар [рхеЁ1х]; 


сопзі ѕігіпд& м = ѕиѓ [капа () % заЁ.3127е()]; 
1Е (м == МОММОВО) 


Ьгеак; 
соцЕ << м << "\п"; 
рхеЁ1х.рор_ЁЕхопе (); // сдвиг вперед 


ргеѓіх.риѕћ раск (м); 


} 


В целом именно эта версия выглядит особенно четко и элегантно. Код компактен, 
структура данных четко определена, алгоритм совершенно очевиден. К сожалению, 
за все приходится платить: Данная версия работает значительно медленнее, чем пер- 
воначальная программа на С, хотя она и не самая медленная. Через некоторое время 
мы еще вернемся к вопросам сравнения быстродействия. 


Упражнение 3.5. К сильным сторонам библиотеки ЅТІ. относится та легкость, 
скоторой ее пользователь может экспериментировать с различными структурами 
данным. Измените приведенную выше программу на С++ так, чтобы для представ- 
ления префиксов, списков суффиксов и таблицы состояний в ней использовались 
другие структуры данных. Как эти изменения влияют на быстродействие? 


Упражнение 3.6. Напишите такую версию программы на С++, в которой бы 
использовались только классы и тип ѕёгіпа, но не применялось бы ни одно из биб- 
лиотечных средств $ТІ.. Сравните ее по стилю и быстродействию с ЗТГ--версией. 


3.7. Амк и Реп 


В завершение нашего упражнения мы написали версии данной программы также 
на двух популярных языках разработки сценариев — А\К и Реп. В них имеются все 
необходимые средства для решения этой задачи, такие как ассоциативные массивы и 
методы обработки строк. 


Ассоциативный массив — это удобный способ представления хэш-таблицы. 
Он очень похож на массив, только его индексами могут быть произвольные числа, 
или строки, или даже списки таких элементов, разделенных запятыми. Это своеоб- 
разная форма установки соответствия между двумя типами данных. В языке АмК 


98 проектирование и реализация Глава 3 


все массивы — ассоциативные, а в Рег| имеются как обычные массивы с целочислен- 
ными индексами, так и ассоциативные массивы (они называются хэш-массивами, что 
однозначно указывает на способ их реализации). 


Версии нашей программы на АжК и Рег! узко специализированы для работы с 
префиксами длины 2. 


# тагкоу.амк: марковский алгоритм с префиксами длиной 2 


ВЕСТМ { МАХСЕМ = 10000; МОММОВО = "\п"; м1 = м2 = МОМИОВр } 
{ Ғор (1=1; 1 <= МЕ; і++) { # считываются все слова 
збабеваЪ [м1, м2, ++п59ЕЕ1х [м1,м2]] = $1 
м1 = №2 
м2 = $1 
} 
ЕМ” { 


збабкевар [м1, м2, ++пзаЕЕ1х [м1,м2]] = МОММОВО # хвост 
м1 = м2 = МОММОВО 
Ғор (і = 0; і < МАХСЕМ; 1++) { # генерируем 
Г = 116 (гапа () *пзаЕЕ1х [м1,м2]) + 1 # пзаЕЕ1хХ >= 1 


р = збабекаь [м1, м2, ү] 
1Е (р == МОММОРР) 
ехіё 
ргіпё р 
м1 = м2 # сдвиг по цепочке 
№2 = р 


АҹК представляет собой язык для работы с шаблонами и образцами. Из входных 
данных считывается одна строка, затем эта строка сравнивается с заданными образ- 
цами, и для каждого найденного совпадения выполняются определенные действия. 
Имеются два особых шаблона, ВЕСТМ и ЕМР”, которые обнаруживаются программой 
перед первой строкой данных и после последней. 

Упомянутые “определенные действия” — это блоки операторов в фигурных скоб- 
ках. В А\К-версии нашей программы блок ВЕСТМ инициализирует префикс и еще 
пару переменных. 

Следующий блок не соответствует никакому образцу, поэтому по умолчанию вы- 
полняется один раз для каждой поступающей строки входных данных. А\К автома- 
тически разбивает каждую прочитанную строку на поля (слова, ограниченные сим- 
волами пустого пространства) с именами от $1 до $МЕ; переменная МЕ обозначает 
количество полей. Следующий оператор строит таблицу соответствий между 
префиксами и суффиксами: 


збабкеваЪ [м1 , м2, ++пѕиЁЁіх [м1,м2]] = $1 


В массиве пзаЕЕ1х подсчитываются суффиксы, а в элементе пзаЕЕ1х [м1, м2] — 
количество суффиксов, ассоциированных с данным префиксом. Сами суффиксы хра- 
нятся в элементах массива ѕсасесар [м1,\м2,1], зкасесар [м1,м2,2] ит.д. 

Блок ЕМ выполняется тогда, когда все входные данные прочитаны. К этому 
моменту с каждым префиксом ассоциируется элемент массива пваЕЁ1х, содержа- 
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щий количество соответствующих префиксу суффиксов, и ровно столько элементов 
массива ѕзсасесар, содержащих сами суффиксы. 

Версия программы на языке Реті устроена похожим образом, но в ней для подсче- 
та суффиксов используется не третий индекс, а анонимный массив. Для обновления 
префикса применяется множественное присваивание. В Рей типы переменных обо- 
значаются специальными символами: $ соответствует скаляру, а @ — индексирован- 
ному массиву, причем квадратные скобки используются для индексирования масси- 
вов, а фигурные — для индексирования хэш-массивов. 


# пагкоу.р1: марковский алгоритм с префиксами длиной 2 


ЅМАХСЕМ = 10000; 


$МОМИОВО = "\п"; 
$м1 = $02 = ЅМОММОВР; # начальное состояние 
мћі1е (<>) { # считывание данных по строке 


Ғогеасһ ($р11%) 
разв (@ {$ зеабеваь {$1} {$м2}}, $); 


($м1, $м2) = (502, 5 ); # множественное присваивание 
разн (@ ($ абебаь{$м1}{5м2}}, ЗМОММОВРО); # хвост 
$м1 = $м2 $МОММОКО ; 


Рог ($51 = 0; $1 < ЅМАХСЕМ; $1++) { 
$з3иЕ = $збабебар {$1} {502}; # обрашение к массиву 
$х = 116 (гапа @$зиаЕЁ); # @$зиЕ - количество элементов 
ех1е 1Е ((5$е = $заЕ->[$:]) еа $МОМИОБВО); 
ргіпё "$6\п"; 
($1, $02) = ($м2, $6); # сдвиг по цепи 


Как и в предыдущих программах, таблица соответствий хранится в переменной 
зсасесаЪ. Самым сердцем программы является следующая строка: 


разн (@ { $зЕакекаь { $1} {$%2}}, $); 


Этот оператор помещает новый суффикс в конец анонимного массива, храняще- 
гося по адресу ѕбасесар{$и1} {$2}. На этапе генерирования выражение 
$зсасекаь{$\1}($\2} является ссылкой на массив суффиксов, а $59Е-> [$51] 
указывает на 7-й суффикс по порядку. 

Программы на А\К и Рег оказались значительно короче своих предшественниц, 
написанных на трех других языках. Но зато их намного труднее адаптировать для 
обработки префиксов длины, отличной от двух. Ядро версии на С++ с применением 
средств ЅТІ. (функции ааа и депекаее) имеет сравнимую длину, однако устроено 
гораздо понятнее. И все же именно языки разработки сценариев часто оказываются 
особенно удачными для программных экспериментов, для написания пробных про- 
тотипов и даже для разработки профессиональных версий программ, если быстро- 
действие не является ключевым требованием. 


Упражнение 3.7. Измените версии программы на языках А\К и Ре! так, чтобы 
они смогли обрабатывать префиксы любой длины. Определите экспериментальным 
путем, как это влияет на быстродействие. 
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3.8. Вопросы быстродействия 


Итак, у нас для сравнения есть несколько программных реализаций одного и того 
же алгоритма. Мы испытали эти программы на Псалтыри (книге “Псалмов Давидо- 
вых”) из англоязычной Библии в канонической редакции короля Иакова. Англий- 
ский текст Псалтыри содержит 42 685 слов (из них 5 238 различных) или 22 482 
префиксов. В этом тексте достаточно много повторяющихся словосочетаний напо- 
добие “Веззе4 1$ фе...” (“Блажен...”), так что один из списков суффиксов содержит 
более 400 элементов, и есть еще несколько сотен цепочек с десятками суффиксов. 
Поэтому данный текст является хорошим тестовым примером. 


В1еззеа 15 ёһе тап оЁ ёһе пеё. Таки ЕБее ипбо ше, апа гаіѕе пе ир, 
Срае І тау ёе11 а11 ту Ееагз. Тһеу 1оокеа опсо Һһіт, һе Һеагӣа. Му 
ргаіѕе ѕһа11 ре Ь1еѕѕеа. Меа1һ апа гісһеѕ ѕһа11 ре ѕауеа. Трои һаѕі 
аеа1б ме11 міёһ ёһу Һіа ёгеаѕиге; ёһеу аге саѕі 1п6о а ѕёбапаіпа мабег, 
ЕћҺе Ғ1іпі 11060 а ѕіёапдіпа мабек, апа аку дгоџпа 1п6о маёегѕргіпаѕ. 
(Блажен муж из сети. Обратись на меня и вознеси меня, дабы поведал я 
все свои страхи. Воззрились они на него, и он услышал. Благословенна 
будь хвала моя. Богатство и богатеи да спасутся. Ты хорошо поступил со 
скрытым сокровищем; они брошены в тихую воду, кремень в тихую воду, и 
землю иссохшую в источники вод.) 


Ниже приведена таблица с данными о времени, которое потребовалось для гене- 
рирования 10 000 слов выходного текста. Эксперименты проводились на компьюте- 
рах МІК В10000 с тактовой частотой 250 МГц под управлением операционной 
системы Ігіх 6.4 и Репіішт П (тактовая частота 400 МГц, 128 Мбайт памяти) под 
управлением Міпіомѕ МТ. Время выполнения задачи почти целиком определяется 
объемом входных данных; генерирование в сравнении с ним происходит очень быст- 
ро. Таблица содержит также примерные длины программ, измеренные в строках 
исходного кода. 


250 МГц, 400 МГЦ, Строк в 
610000 Репйит П исходном коде 
С 0,36с 0,30 с 150 
Јаға 4,9 9,2 105 
С++/5ТІ /очередь | 2,6 11,2 70 
С++/5ТГ/список 17 1,5 70 
А\К 2,2 2,1 20 
Рег] 1,8 1,0 18 


Версии на языках С и С++ компилировались оптимизирующими компилятора- 
ми, а при запуске программы на Јауа разрешалась компиляция по требованию. Вре- 
мя выполнения программ на С и С++ в системе [гіх было отобрано как лучший ре- 
зультат из числа выданных тремя разными компиляторами. Подобные же результа- 
ты наблюдались на машинах Ѕип ЗРАКС и РЕС АШБа. С-версия этой программы 
быстрее остальных во много раз. Второе место по быстродействию занимает Рег. 
И все же данные, представленные в нашей таблице, получены в частном случае для 
определенного набора компиляторов и библиотек, поэтому в другой среде экспери- 
ментальные результаты могут сильно отличаться. 
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Совершенно очевидно, что версия с использованием очередей (деаие) из биб- 
лиотеки ЗТГ. в системе \/п4о\з содержит какой-то принципиальный недостаток. 
Эксперименты показали, что именно двусторонняя очередь для представления пре- 
фиксов виновата в потере машинного времени, хотя она и не содержит более двух 
элементов. Скорее мы ожидали, что основным виновником окажется центральная 
структура данных — таблица соответствий. Переход от очереди к списку (в ТТ. это 
двусвязный или двунаправленный список) радикально улучшает быстродействие. 
С другой стороны, переключение с таблицы на нестандартный контейнер ВазН ока- 
залось вообще незаметным в системе Їгіх. В системе Уп4о\з такая структура дан- 
ных была недоступна. То, что структуры данных в ТІ. фундаментально продуманы 
и спроектированы с высоким качеством, легко видеть из того факта, что подобные 
переходы потребовали всего лишь подстановки слова 115 вместо слова десие или 
Һаѕһ вместо тар в двух местах исходного кода и перекомпиляции программы. Оста- 
ется заключить, что библиотека ЗТТ., новейший компонент языка С++, все еще гре- 
шит несовершенствами реализации. Соотношение быстродействия между програм- 
мами со специально разработанными структурами данных и программами со струк- 
турами из ЅТІ. совершенно непредсказуемо. То же самое верно и в отношении языка 
Јама, в котором различные реализации сменяют друг друга очень быстро. 

Здесь имеются интересные направления для дальнейшего экспериментирования, 
например, тестирование программы с большим запрашиваемым объемом текста на 
выходе. Откуда нам знать, работает ли она вообще? Как убедиться в том, что про- 
грамма часть своего времени не теряет впустую? В главе 6, посвященной вопросам 
тестирования, даны некоторые рекомендации, а также описано, как мы тестировали 
программу с марковским алгоритмом. 
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Программа работы с текстом на основе цепей Маркова имеет долгую историю. 
Первую версию написал Дон Митчелл (Поп Р. МЁсБе!), адаптировал Брюс Эллис 
(Вгасе ЕШ5), и в 1980-х годах она использовалась для различных курьезных демон- 
страций, связанных с перетасовкой данных. Эта программа лежала без дела до тех 
пор, пока мы не решили использовать ее в университетском курсе для иллюстрации 
процесса разработки программ. Вместо того чтобы сдувать пыль с оригинала, мы 
написали программу заново на языке С, по ходу освежая воспоминания о возни- 
кающих при этом проблемах, а затем перевели еще на несколько языков, стараясь 
выразить одну и ту же идею по-разному идиоматическими средствами каждого язы- 
ка. После окончания курса мы еще многократно переработали эти программы, 
постепенно улучшая четкость их структуры и наглядность представления операций. 

Тем не менее все это время основной подход, костяк алгоритма, оставался тем же 
самым. Более ранняя версия реализовала тот же подход, что и представленная в этой 
главе, только в ней использовалась вторая хэш-таблица, содержащая отдельные сло- 
ва. Если бы нужно было переписать программу еще раз, мы бы вряд ли стали что-то 
менять. Структура программы вырастает из организации ее данных. Структуры 
данных, конечно, не определяют реализацию программы вплоть до мелких подроб- 
ностей, но несомненно придают ей общую форму. 
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Выбор между некоторыми структурами данных оказывается непринципиальным, 
например, отличие между списком и расширяемым массивом в данной программе 
несущественно. В некоторых реализациях степень общности алгоритма выше или 
ниже, чем в других. Так, в программах на АмК и Рег| можно довольно просто перей- 
ти к префиксам из одного или, скажем, трех слов, а вот параметризация для работы с 
префиксами произвольной длины уже представляет собой проблему. Как и подобает 
объектно-ориентированным языкам, в С++ и Јауа требуются совсем крошечные из- 
менения в программах, чтобы приспособить структуры данных к обработке другой 
информации, отличной от литературного английского текста. Это могут быть, на- 
пример, исходные тексты программ (где символы пустого пространства играют 
большую роль), или музыкальные ноты, или даже щелчки мышью и выбор пунктов 
меню, позволяющие генерировать текстовые последовательности. 

Разумеется, хотя структуры данных остаются более-менее теми же самыми, воз- 
можны большие вариации в общем строении программ, длине их исходного кода и 
быстродействии. Грубо говоря, языки высокого уровня порождают более медленный 
код, чем языки низкого уровня; конечно, несмотря на это, мы неизменно стремимся к 
качественному обобщению. Большие структурные единицы программ, такие как 
библиотечные средства ТІ. в С++ или ассоциативные массивы и методы работы со 
строками в языках разработки сценариев, позволяют добиться компактности исход- 
ного кода и выполнить работу в кратчайшие сроки. За это приходится расплачивать- 
ся падением скорости выполнения, хотя быстродействие и не всегда играет большую 
роль в таких программах, которые выполняются всего несколько секунд. 

Менее очевидным представляется вопрос о том, как же оценить степень потери кон- 
троля над программой в том случае, когда системные и библиотечные средства, нагро- 
мождаясь друг на друга, образуют такую кучу, в которой уже непонятно, что происходит 
на нижнем уровне организации. Именно так обстоят дела с ЅТІ -версией программы — ее 
быстродействие непредсказуемо, и простого способа исправить ситуацию не существует. 
Одна из недоработанных реализаций этой библиотеки потребовала серьезной перера- 
ботки, прежде чем она вообще смогла обеспечить выполнение нашей программы. Лишь у 
немногих из нас хватает энергии проследить такую проблему до конца и разрешить ее. 

В индустрии разработки программного обеспечения существует давняя, повсеме- 
стная и все усугубляющаяся проблема: библиотеки, интерфейсы и инструменталь- 
ные средства становятся все сложнее, и по мере этого уровень понимания и способ- 
ность ими управлять сильно падают. Когда все работает как следует, развитые среды 
программирования позволяют добиться очень высокой производительности труда, 
но если вдруг возникает сбой, то деваться некуда. Можно вообще не понять, что про- 
блема существует и где ее источник, если речь идет о необъяснимом падении быст- 
родействия или тонких ошибках в управляющих конструкциях. 

Проектирование и реализация приведенных программ позволяет извлечь ряд уро- 
ков на будущее, для целей разработки более сложных и длинных программ. 
Во-первых, важно вначале выбрать простые алгоритмы и структуры данных — про- 
стейшие из тех, что способны выполнить работу ожидаемого объема за разумное вре- 
мя. Если такие средства уже кем-то написаны и объединены в библиотеку, тем луч- 
ше — именно с использованием подобных средств мы и написали нашу версию на С++. 
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Следуя принципу, приведенному в эпиграфе, мы начали с тщательного конст- 
руирования структур данных, имея в виду алгоритм, который будет к ним приме- 
няться. Подготовив структуры данных, мы легко собрали код воедино. 

Трудно спроектировать программу полностью и сразу же реализовать ее; при 
написании реальных программ неизбежен процесс последовательных приближений 
и экспериментирования. Написание кода требует от программиста четкой проработ- 
ки тех конструкций и технических решений, в отношении которых на этапе замысла 
еще можно было обойтись натяжками и прикидками. Именно так и обстояло дело с 
нашими программами из этой главы, которые подверглись неоднократной доработке 
и переработке. По возможности всегда начинайте с чего-то самого простого и дви- 
гайтесь вперед, как вам подсказывает опыт. Если бы наша цель заключалась только в 
том, чтобы написать версию марковского алгоритма для личного пользования и раз- 
влечения, мы бы почти наверняка обошлись вариантом на АмК или Рей (причем не 
столь тщательно проработанным), не вдаваясь в тонкости. 

Однако коммерческая или профессиональная версия программы всегда отнимает 
больше времени и усилий, чем ее технический прототип. Если бы программы, рас- 
смотренные в этой главе, пришлось пускать в профессиональную работу, это было 
бы возможно — они всесторонне протестированы и выверены по стилю. Достижение 
профессионального качества требует на порядок или два больше трудозатрат, чем 
разработка программы для личного пользования. 


Упражнение 3.8. Мы знакомы с версиями нашей программы реализации марков- 
ских цепей на целом ряде языков: Ѕсһете, Тсі, Рго]оз, Руфоп, Сепегіс Јауа, МГ. и 
Назке|]; каждый из них имеет свои преимущества и проблемные места. Напишите 
эту же программу на одном из ваших любимых языков и сравните ее стиль и быст- 
родействие с существующими. 


Дополнительная литература 

Стандартная библиотека шаблонов ЅТІ. описана во многих книгах, среди которых: 
Майћем Аизегп, Сепепс Рюортатттё апа ше 511. (Аайіѕоп-МеѕІеу, 1998). В качестве 
справочника по языку С++, несомненно, стоит рекомендовать книгу Вјагпе Ѕігоцѕїгир, 
Тһе С++ Рюортатпиия Гаприаре (Зта е4 оп, Аайіѕоп-М№еѕІеу, 1997). Что касается Јама, 
можно воспользоваться книгой Кеп АгпоЇа, Јатеѕ Соѕ!іпе, Тйе Лаба Руортаттіпр Гаприа- 
ре, 2па Еаіноп (Аааіѕоп-Меѕ1еу, 1998). Лучшее описание языка Рег! дано в книге [агу 
УҰа]ї, Тот Сһгіѕйапѕеп, Вапаа! Ѕсһмагіх, Руортаттіпр Рен, 2па Ейіноп (О’КеЩу, 1996). 

Существует идея структурных шаблонов (4еяеп райет5), заключающаяся в том, 
что все программы строятся на основе лишь нескольких фундаментальных органи- 
зующих конструкций, точно так же, как все задачи реализуются на основе комбина- 
ций из нескольких базовых структур данных. Очень приблизительно можно сказать, 
что это аналоги идиоматических программных конструкций, рассмотренных в гла- 
ве 1. Общепринятым справочником по этим вопросам является книга Егісћ Сатта, 
Кісһага Нет, Кафь ]оБлзоп, Јоһһ \“1іѕѕіаеѕ, Деяеи Райетѕ: Иететб оў ВеиѕаЫе 
Орјесі-Опепіеа 5оўёоат (Айаіѕоп-Меѕеу, 1995). 

Невероятные приключения программы тагкКоу, первоначально существовавшей 
под именем ѕһћапеу, были описаны в рубрике “Сотрибіпе Кесгеаїйопѕ” журнала 
5сіепіјіс Атепсап за июнь 1989 года. Эта же статья была перепечатана в книге 
А.К.Юемапеу, Тле Мас Масйте (№. Н. Егеетап, 1990). 


Интерфейсы 


Уж раз мы строим стену, надо знать, 
Что защитит она, и от кого, 

И вчем кому-то от меня обида. 

Есть нелюбовь какая-то к стене, 
Мечта ее обрушить! 


Роберт Фрост. “Починка стены”' 
(Кођет Егоѕі, Мепашв Ма) 


В процессе разработки программ приходится постоянно балансировать между 
трудно совместимыми целями и удовлетворять противоречивым ограничениям. Да- 
же при написании небольшой автономной системы приходится идти на многие ком- 
промиссы, но там сделанный выбор по крайней мере остается спрятанным внутри и 
оказывает влияние только на работу самого автора программы. А вот если код необ- 
ходимо передавать для использования другим людям, то сделанные выборы и ком- 
промиссы будут иметь гораздо более отдаленные последствия. 

Среди вопросов, которые необходимо проработать при проектировании програм- 
мной системы, имеются следующие. 


• Интерфейсы: какие услуги и какой доступ к ним необходимо предоставить? 
Интерфейс — это по сути договор между поставщиком и заказчиком. Обычно 
стремятся обеспечить удобный и единообразный набор услуг, чтобы функцио- 
нальные возможности были под рукой в достаточном количестве, но не слиш- 
ком загромождали оперативное пространство. 


• Сокрытие информации: какие данные должны быть видимы пользователю, 
а какие — скрыты от него? Интерфейс должен обеспечивать несложный доступ 
к компонентам и при этом скрывать детали реализации так, чтобы ее можно 
было дорабатывать незаметно для пользователя. 


• Управление ресурсами: кто должен отвечать за распределение памяти и других 
ограниченных ресурсов? Основные проблемы — это как размещать и удалять 
объекты из памяти и как распоряжаться совместно используемыми экземпля- 
рами данных. 


• Обработка ошибок: как распознавать ошибки и выдавать сообщения о них? 
Какие меры необходимо принять, если произошла та или иная ошибка? 


1 Перевод А. Цветкова 
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В главе 2 рассматривались элементарные “кирпичики” — структуры данных, из 
которых строятся программы. В главе З изучался вопрос, как объединить такие 
“кирпичики” в одну небольшую программу. Теперь же нашей темой будет организа- 
ция интерфейсов между компонентами, которые, вполне возможно, происходят из 
разных источников. В этой главе мы проиллюстрируем проектирование интерфейса 
на примере разработки библиотеки функций и структур данных для одной распро- 
страненной задачи. Попутно будут рассмотрены некоторые принципы проектирова- 
ния программ. Как правило, в такой работе приходится принимать невероятное 
количество решений, но большинство из них — почти бессознательно. Не имея на 
вооружении нужных принципов, можно лишь нагромождать бессистемные 
конструкции, постоянно мешающие программистам в работе и раздражающие их. 


4.1. Данные, разделенные запятыми 


Данные, разделенные запятыми (Сотта-берагиеа Үаіиеѕ, или С5У), — это тер- 
мин для естественного и часто встречающегося способа представления табличных 
данных. Каждая строка таблицы представляет собой строку текста; поля в каждой 
строке отделяются друг от друга запятыми. Например, английский оригинал табли- 
цы, приведенной в конце предыдущей главы, мог бы начинаться в этом формате сле- 
дующим образом: 


‚"250МН2", "400МН2", "Ъ1пез оЁ" 

‚ "610000", "РепЕ1ам ТТ", "ѕоцгсе соае" 
С, 0.36 зес,0.30 зес,150 
Јауа,4.9,9.2,105 


В таком формате данные считываются и записываются программами работы с 
электронными таблицами. Не случайно именно в этом формате они фигурируют и 
на \!еБ-страницах, посвященных услугам типа биржевых котировок. Одна из попу- 


лярных \!еБ-страниц биржевых котировок представляет информацию примерно в 
следующем виде. 


Скачать в формате электронной таблицы 


Считывать цифры из окна М№еЬ-браузера довольно удобно, однако это отнимает 
много времени. Представьте себе всю эту волокиту: запустить браузер, подождать, 
прорваться через рекламный мусор на экране, ввести интересующие вас наименова- 
ния, снова подождать (на этот раз еще дольше), снова терпеливо снести рекламу, и все 
ради нескольких цифр. К тому же дальнейшая обработка этих цифр требует дополни- 
тельных операций. После щелчка на ссылке “Скачать в формате электронной табли- 
цы” откроется файл, содержащий ту же информацию в виде строк данных, разделен- 
ных запятыми (здесь эти данные отредактированы, чтобы помещаться в строки): 
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"О", 86.25, "11/4/1998", "2:19РМ", +4.0625, 
83.9375, 86.875, 83 .625,5804800 

"Т", 60.6875, "11/4/1998", "2:19РМ", -1.1875, 
62.375,62.625,60.4375, 2468000 

"МЅЕТ",106.5625, "11/4/1998", "2:24РМ",+1.375, 
105 .8125,107.3125,105.5625, 11474900 


Что во всей этой процедуре мозолит глаза, так это отсутствие главного преиму- 
щества компьютеризации — автоматической обработки данных. С помощью браузе- 
ра можно обращаться к данным на сетевом сервере, но было бы еще удобнее загру- 
жать их на свой компьютер автоматически, без принудительного вмешательства. 
За всеми этими щелчками на кнопках стоит чисто текстуальная процедура: браузер 
считывает НТМГТ-код, вы вводите текст, браузер посылает его на сервер и снова счи- 
тывает оттуда НТМГ-код. Имея под рукой нужные средства и соответствующий 
язык, можно легко получить эту информацию автоматически. Ниже приведена про- 
грамма на языке Тс] для обращения к МеЬ-сайту биржевых котировок и загрузки 
данных в показанном выше С$У-формате с несколькими строками заголовка, пред- 
варяющими сами данные. 


# сдесацоёеѕ.іс1: биржевые котировки Гасепе, АТ&Т и Місгоѕоѓі 


ѕес зо [ѕоске аџооёе.уаһоо. сом 80] ;# соединение 
ѕес а "/а/аџобеѕ.сѕу?ѕ=_0+Т+МбЕТЕҒ-5111161с1оһду" 


риєѕ $в0 "СЕТ $а НТТР/1.0\х\п\к\п" ;# запрос 


Ғ1ІЧѕһ $ѕо 
роёѕ [хеаа $30] ;# чтение и ответ 
Загадочная строка #=... после символов акций представляет собой недокумен- 


тированную управляющую строку, аналогичную первому строковому аргументу 
функции ре1пЕЕ. Она определяет, какие данные нужно загрузить. Путем экспери- 
ментирования мы определили, что ѕ обозначает символ акции, 11 — последнюю це- 
ну, с1 — изменение цены со вчерашнего дня и т.д. Но важны не столько сами детали, 
которые все равно со временем изменяются, сколько возможность автоматизации: 
получение требуемой информации и преобразование ее в нужную форму без вмеша- 
тельства человека. Таким образом, машина сама делает всю работу. 

Для выполнения программы зесааосез обычно требуется доля секунды, 
т.е. намного меньше, чем для работы с браузером. Получив данные, необходимо 
дополнительно обработать их. Такие форматы, как СЅУ, удобны для работы в том 
случае, если имеются библиотеки для преобразования данных из этого формата и в 
него, а также для некоторых дополнительных операций наподобие преобразований 
чисел. Но нам неизвестна ни одна библиотека открытого пользования для работы 
с форматом С$У, поэтому придется написать ее самостоятельно. 

В следующих разделах мы создадим три версии библиотеки для считывания дан- 
ных, разделенных запятыми, и преобразования их в международные представления. 
Заодно мы поговорим о проблемах, которые возникают при разработке программ, 
взаимодействующих с другими программами. Например, не существует стандартно- 
го определения формата СЅҮ, поэтому реализация библиотеки не может основы- 
ваться на точной спецификации. Это весьма распространенная ситуация при разра- 
ботке интерфейсов. 
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4.2. Прототип библиотеки 


Маловероятно, чтобы удалось правильно спроектировать библиотеку или интер- 
фейс с первой же попытки. Как однажды написал Фредерик Брукс (Етеегіск 
ВгооКѕ): “..заранее приготовьтесь выбросить ваше творение; все равно придется”. 
Брукс писал о больших системах, но эта мысль справедлива в отношении всякого 
более-менее существенного программного продукта. Часто бывает так, что програм- 
ма уже написана и используется некоторое время, и только после этого к ее автору 
наконец приходит понимание, как же она должна быть устроена. 

Настроившись на этот оптимистический лад, приступим к созданию библиотеки 
для работы с СЗУ-данными, которую потом придется выбросить, — ее прототипа. 
В первой версии мы будем игнорировать большинство трудных мест, учитываемых в 
законченном профессиональном продукте, но тем не менее библиотека будет доста- 
точно полной и работоспособной, чтобы на ее примере ознакомиться с проблемой. 

Начнем с функции сзудеЕ11пе, которая считывает одну строку С5У-данных из 
файла в буфер, разбивает ее на поля, помещает поля в массив, удаляет кавычки и 
возвращает количество полей. В течение многих лет мы программировали нечто 
подобное практически на всех языках, так что это не новая задача. Ниже приведена 
пробная версия на С; она помечена вопросительными знаками, потому что это всего 
лишь прототип, требующий серьезной доработки. 


Е1е1а[пЕ1е1а++] = ипацоее (р); 
хебигп пЕ1е1а; 


? сһаг рц [200]; /* буфер для строки */ 

? сһаг *Ғіе1а[20]; /* поля */ 

су 

? /* сѕудес1іпе: ввод и разбиение строки; возвращает количество 
полей */ 

Е /* пробные данные: "БИ", 86.25, "11/4/1998", "2:19РМ", +4.0625 */ 
? 106 сзуаее11пе(ЕТЬЕ *Ғіп) 

2 

? 106 пѓЁіе1а; 

? сһаг *р, *а; 

Э 

? 1Е (ЕчеЕз(роЁ, ѕітлеоѓ (риё), Е1п) == МО) 

? геёигп -1; 

? пЁҒіе1а = 0; 

? Ғог (а = Биё; (р=ѕігіок (а, ",\п\г")) != МЈ; а = МО) 

2 

8. 

2 


} 


Комментарий перед началом функции содержит образец входных данных для 
программы; такие комментарии бывают полезны, если программа должна воспри- 
нимать и анализировать данные сложного формата. 

СЅҰ-данные устроены слишком сложно, чтобы с ними справилась функция 
зсапЕ. Вот почему мы воспользовались библиотечной функцией ѕегёок. При каж- 
дом вызове зЕтеоКк (р, ѕ) возвращается указатель на первую лексему в строке р, 
не содержащую символов из з; функция зЕкеоК завершает лексему, заменяя сле- 
дующий символ исходной строки нулевым байтом. При первом вызове первый 
аргумент ѕбгіок равен исходной анализируемой строке. При последующих вызовах 
этот аргумент равен МОТ, что требует от функции продолжать разбор строки с того 
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места, где он закончился в прошлый раз. Это довольно посредственный способ. 
Поскольку неизвестно, где хранится строка между вызовами функции зЕкеЕок, 
одновременно может быть активна только одна последовательность вызовов. Пере- 
межающиеся асинхронные вызовы могут помешать друг другу. 

Функция ипачоее удаляет открывающие и закрывающие кавычки, фигурирую- 
щие в приведенных выше пробных данных. Но вложенные кавычки она обрабаты- 
вать не умеет, поэтому как прототип она хороша, а до окончательного варианта еще 
не дотягивает. 


? /* опачобе: удаление открывающих/закрывающих кавычек */ 
? сһаг *опачоѓе (сһаг *р) 

? 

? 1Е (р [0] Рея тиу) { 

? 1Е (р[з6х1еп(р)-1] == '"'!) 

2 р[зЕк1еп(р)-1] = '\0'; 

? р++; 

? 

? геёогп р; 

? 


} 


Проверить работу функции сѕудес1іпе можно с помощью простейшей тесто- 
вой программы: 


? /* сѕубеѕё таіп: тестирует функцию сѕудеб1іпе */ 

2 106 таіп (уоіа) 

? 

? ТЕХ ИЕ 

? 

? мһі1е ((пЕ = сѕудес1ііпе (з6а1п)) != -1) 

? Ғог (і = 0; і < ПЕ; 1++) 

? ре1пЕЕ ("Ғіе1а[%0] = `%5'\п", 1, Е1е1а[1]); 
? геіицгп 0; 

? 


} 


Функция ре1пЕЕ заключает поля в одинарные кавычки, что позволяет четко 
выделить их, а также помогает выявить ошибки при обработке символов пустого 
пространства. 

Запустим эту программу и зададим ей исходные данные, загруженные с 
Уер-сайта программой десаооёсеѕ.ёс1: 


% десацосез.ісі | сзубезЕ 


Ғіе1а [0] = 'Ш0' 


Ғіе1а [1] = '86.375' 
Ғіе1а [2] = '11/5/1998' 
Ғіе1а [3] = '1:01РМ' 
Ғіе1а [4] = '-0.125' 
Ғіе1а [5] = '86' 

Ғіе1а [6] = '86.375' 
Ғіе1а [7] = '85.0625' 
Ғіе1а [8] = '2888600' 
Ғіе1а [0] = 'Т' 


Ғіе1а [1] = '61.025' 
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(В этом примере отброшены заголовки НТТР.) 

Итак, мы имеем прототип, который, похоже, вполне способен работать с данными 
того типа, который показан выше. Но разумно было бы попробовать его и на других 
данных тоже, особенно если мы собираемся передавать разработанные функции 
другим пользователям. Мы нашли еще один Мер-сайт с биржевыми котировками и 
получили файл аналогичной информации, но в несколько другой форме: записи от- 
деляются символами возврата каретки (\г) вместо символов конца строки, а в конце 
файла такие символы не ставятся. Вот эти данные, отформатированные под печат- 
ную страницу: 

"Тіскег", "Ргісе", "Сһапде", "Ореп","Ргеу С1оѕе", "Рау Нідһ", 
"Рау Том", "52 Иеек Нідһ", "52 Меек Гом", "Ріуіадепа", 
"Үіе1а", "Уоїцте", "Ауегаде УоІцте", "Р/Е" 

"ГО", 86.313,-0.188, 86.000,86.500, 86.438,85.063, 108.50, 
36.18,0.16,0.1,2946700, 9675000, М/А 

"Т", 61.125,0.938, 60.375, 60.188, 61.125,60.000,68.50, 
46.50,1.32,2.1,3061000, 4777000,17.0 


"М5ЕТ", 107.000,1.500,105.313,105.500,107.188,105.250, 
119.62,59.00,М/А, М/А, 7977300, 16965000, 51.0 


Получив на вход эти данные, наша пробная программа с позором провалилась. 
Дело в том, что мы разработали наш прототип на основе одного источника данных и 
тестировали программу только на этом же источнике. Поэтому не стоит удивляться, 
что первая же встреча с другими данными закончилась столь плачевно. Длинные стро- 
ки, множество полей, неожиданные или пропущенные разделители — все это потенци- 
альные источники проблем. Наш черновой прототип может годиться для личного 
пользования или для демонстрации общего подхода, но не более того. Перед тем как 
переделывать программу, следует более тщательно подойти к ее проектированию. 

При создании прототипа мы уже приняли целый ряд решений, как явных, так и 
неявных. Ниже перечислены некоторые из сделанных предположений и принятых 
решений, причем не всегда наилучших для библиотеки общего пользования. Каждое 
из них порождает проблемы, требующие более пристального внимания. 


® Программа не обрабатывает длинные строки данных или большое количество 
полей. Она дает неправильные ответы или вообще завершается аварийно, 
потому что даже не проверяет переполнение, не говоря уже о том, чтобы воз- 
вращать специальные коды в случае ошибок. 


е Предполагается, что исходные данные состоят из строк, разделенных симво- 
лами конца строки. 


• Поля отделяются друг от друга запятыми, а окружающие их кавычки удаляют- 
ся. Вложенные запятые или кавычки никак не обрабатываются. 


• Исходная строка не сохраняется, а затирается в процессе ее разбиения на поля. 


• При переходе от одной строки данных к другой не запоминаются никакие дан- 
ные; если все же что-то нужно будет запомнить, придется сделать копию. 


• Обращение к полям выполняется через глобальную переменную (массив 
Ғіе1а), совместно используемую функцией сѕудеё1іпе и функциями, ее 
вызывающими. Не осуществляется никакого контроля над обращениями к 
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содержимому полей или указателям на них. Обращение к полям за пределами 
последнего также никак не блокируется. 


® Наличие глобальных переменных делает Данную реализацию неподходящей 
для многопоточных сред или даже для двух последовательностей поочередных 
ВЫЗОВОВ. 


® Вызывающий модуль должен сам открывать и закрывать файлы — функция 
сзудее1 1пе считывает информацию только из открытых файлов. 


® Ввод данных и их разбиение на поля неразрывно связаны: при каждом вызове 
функции строка автоматически вводится и разбивается на поля независимо от 
того, необходима ли программе эта операция. 


® Возвращаемое значение равно количеству полей в строке; чтобы вычислить это 
значение, необходимо разбить строку на поля. Также нет способа отличить 
ошибку от конца файла. 


® Не существует другого способа изменить какую-либо из перечисленных харак- 
теристик программы, кроме непосредственной модификации исходного кода. 


Этот длинный, хотя и неполный список иллюстрирует некоторые из компромис- 
сов, на которые идет программист. Каждое из проектных решений явно или неявно 
вплетается в код. Для одноразовой задачи — например, считывание данных одного 
фиксированного формата из одного известного источника — это вполне нормально. 
Но что если формат изменится, или внутри кавычек появится запятая, или сервер 
сгенерирует длинную строку с большим количеством полей? 

Все эти проблемы кажутся легко решаемыми, поскольку “библиотека” очень ма- 
ленькая и в любом случае представляет собой всего лишь прототип. Однако пред- 
ставьте себе, что она проваляется на полке несколько месяцев или лет, а затем вой- 
дет в состав большой программы, спецификации и интерфейсы которой изменяются 
со временем. Как тогда приспособится к этой ситуации функция сѕудес1іпе? Если 
программа должна использоваться другими людьми, то компромиссные решения, 
принятые при проектировании прототипа, могут обернуться в отдаленном будущем 
негативными последствиями. По этому сценарию уже развивалась история многих 
плохо спроектированных интерфейсов. Следует с прискорбием отметить, что многие 
быстро и плохо написанные модули кода со временем вошли в популярные про- 
граммные продукты, оставшись в их составе такими же низкокачественными, но уже 
гораздо менее быстрыми. 


4.3. Библиотека для общего пользования 


Вооружившись знаниями о поведении прототипа, приступим к разработке библио- 
теки, достойной передачи в другие руки. Наиболее очевидное требование — это сде- 
лать функцию сэудее11пе более устойчивой к длинным строкам и большому коли- 
честву полей. Следует также тщательнее отнестись к разбиению строк данных на поля. 

Чтобы разработать интерфейс, которым могли бы пользоваться другие люди, 
необходимо учесть вопросы, поставленные в начале главы: внешний интерфейс, 
сокрытие информации, управление ресурсами и обработка ошибок. Соотношение между 
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этими требованиями сильно влияет на структуру модулей библиотеки. Наша классифи- 
кация данных требований несколько условна, поскольку все они взаимосвязаны. 


Интерфейс. Мы выбрали для реализации три основные операции: 


сһаг *сѕудеб1іпе (ЕТЬЕ *): считывание новой строки СЗУ-данных; 
сһаг *сѕуЁіе1а (іпє п): получение п-го поля текущей строки; 
іп свупЕзе1А (уоіа): получение количества полей в текущей строке. 


Какое значение должна возвращать функция сѕзудес1іпе? Желательно, чтобы 
она возвращала как можно больше полезной информации в удобной форме, напри- 
мер, количество полей, как и в прототипе. Но в таком случае количество полей при- 
дется вычислять даже в том случае, если сами поля не используются. Еще одно воз- 
можное возвращаемое значение — это длина строки исходных данных, на которую 
влияет то обстоятельство, сохраняется в строке завершающий ее нулевой символ 
или нет. После ряда экспериментов мы решили, что функция сзудее11пе должна 
возвращать указатель на исходную строку или МОТ: если встретился конец файла. 

Символ конца строки будет удаляться из строки исходных данных, возвращае- 
мой функцией сѕзудеё1іпе, поскольку по необходимости его легко восстановить. 

Определить, что такое поле — непростое дело. Мы попытались обобщить наши 
эмпирические наблюдения, почерпнутые из электронных таблиц и других аналогич- 
ных программ. Поле — это последовательность из нескольких символов (в частном 
случае — ни одного). Поля отделяются друг от друга запятыми. Пробелы в начале и 
в конце поля сохраняются. Поле может быть заключено в двойные кавычки, и в этом 
случае в его состав могут входить запятые. Поле в кавычках может также содержать 
символы двойных кавычек, для обозначения которых используются сразу два таких 
символа подряд; так, поле "х" "у" обозначает строку данных х"у. Поля могут быть 
пустыми; например, кавычки без других символов между ними ("") как раз обозна- 
чают пустое поле, так же как и отсутствие символов между двумя запятыми. 

Поля нумеруются начиная с нуля. А что если пользователь запросит несущест- 
вующее поле, сделав вызов сѕуѓіе1а(-1) или сзуЕ1е1 а (100000) ? Можно возвра- 
тить строку "" (пустое поле), поскольку ее можно выводить на экран или сравнивать с 
другими строками. Программы, работающие с переменным количеством полей, не обя- 
заны принимать специальные меры по обращению с несуществующими строками. 
Второй вариант — это вывести сообщение об ошибке или даже завершить программу 
аварийно. Вскоре мы обсудим, почему это нежелательно. Мы решили возвращать зна- 
чение МОТ, — обычное обозначение для несуществующей строки в языке С. 


Сокрытие информации. Библиотека не должна накладывать никаких ограниче- 
ний на длину входной строки или количество полей в ней. Чтобы этого добиться, 
нужно либо заставить вызывающий модуль обеспечить вызываемые функции доста- 
точным количеством памяти, либо вызываемые (библиотечные) модули должны 
позаботиться о ее распределении. Например, при вызове библиотечной функции 
Едеез в нее передается массив и его максимальная длина. Если вводимая строка 
длиннее буфера, она разбивается на части. Этот способ неприемлем для 
С$У-интерфейса, поэтому наша библиотека будет сама распределять дополнитель- 
ное количество памяти, если ее окажется недостаточно. 
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Таким образом, только функции сзуаеЕ11пе известно о выполняемом ею рас- 
пределении памяти; никакая информация о том, как именно она это делает, не про- 
сачивается наружу. Такое сокрытие данных лучше всего осуществить через интер- 
фейс библиотеки: сѕудеё1іпе будет считывать следующую строку, какова бы ни 
была ее длина, сѕу#іе1а (п) — возвращать указатель на байты п-го поля текущей 
строки, а сэупЕ1е1а — возвращать количество полей в текущей строке. 

По мере поступления более длинных строк или большего количества полей при- 
дется наращивать объем используемой памяти. Подробности этих операций скрыты 
в сѕу-функциях, и никакие другие части программы не имеют о них понятия — 
например, используются ли изначально малые, но растущие массивы, или же масси- 
вы очень большой длины, или вообще совершенно другие структуры данных. 
Интерфейс также скрывает от пользователя момент освобождения памяти. 

Если пользователь вызывает только функцию сѕудеб1іпе, то нет необходимо- 
сти разбивать ее на поля; это можно сделать по специальному требованию. От поль- 
зователя скрывается и такая подробность реализации, как разбиение строки на поля: 
выполняется ли оно немедленно (сразу после считывания строки), по общему требо- 
ванию (когда запрашивается количество полей или какое-нибудь из них) или по 
специальному требованию (тогда извлекается только запрашиваемое поле). 


Управление ресурсами. Необходимо решить, кто будет отвечать за совместно 
используемые данные. Должна ли функция сѕучес1іпе возвращать исходный эк- 
земпляр данных или делать их копию? Мы решили, что сзуцее11пе будет возвра- 
щать указатель на исходную строку данных, которая затирается при следующем 
считывании. Поля формируются в копии исходной строки, а функция сѕуѓіе1а 
возвращает указатель на конкретное поле в копии строки. В этом случае пользова- 
тель должен сам сделать копию, если он хочет сохранить или изменить какое-либо 
поле или строку. Ответственность за освобождение памяти, когда она становится 
ненужной, возлагается на пользователя. 

Кто должен открывать и закрывать файл исходных данных? Тот, кто его откры- 
вает, должен и закрывать: парные задачи должны выполняться на одном и том же 
уровне или в одном модуле. Предполагается, что функция сзудее1 1пе будет вызы- 
ваться с указателем типа ЕТЬЕ на уже открытый файл, который вызывающая функ- 
ция закроет сама в нужный момент. 

Управление ресурсами, которые совместно используются или передаются через 
границу, разделяющую вызывающий модуль и библиотеку, представляет собой 
сложную задачу. Часто выбор тех или иных предпочтений диктуется хоть и разум- 
ными, но весьма противоречивыми соображениями. Ошибки и недоразумения при 
управлении совместными ресурсами порождают много сбоев в программах. 


Обработка ошибок. Поскольку функция сѕудеб1іпе в случае неудачи всегда 
возвращает значение МО11, нет надежного способа отличить конец файла от ошиб- 
ки — например, нехватки памяти. Аналогично, при обращении к несуществующему 
полю не возникает состояние ошибки. По аналогии с Ееггог можно было бы доба- 
вить к интерфейсу еще одну функцию сѕудеёеггог для получения информации о 
последней сделанной ошибке, но в этой версии библиотеки мы опустили данное 
средство для простоты. 
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В принципе, библиотечные функции не должны просто завершаться аварийно, 
если случается ошибка; тип ошибки необходимо сообщить вызывающему модулю, 
чтобы тот принял надлежащие меры. Не следует также выдавать сообщения об 
ошибках или открывать диалоговые окна, поскольку программа может выполняться 
в среде, где это неуместно и будет мешать работе. Обработка ошибок — это важная 
тема, которую стоит обсудить отдельно. Мы рассмотрим ее позже в этой же главе. 


Спецификация. Принятые ранее решения следует собрать в одном месте в виде 
спецификации задач, которые должна выполнять функция сзудее1 1пе, и способов ее 
использования. В большом проекте спецификация (иначе называемая техническим 
заданием) обязательно предшествует реализации, потому что авторы технического 
задания и авторы программы — обычно разные люди, часто даже из разных 
организаций. Тем не менее на практике часто случается, что оба эти вида работ 
выполняются параллельно: спецификация и код эволюционируют одновременно. 
Иногда такое “техническое задание” даже пишется после того, как программа уже 
разработана, фиксируя в виде требований то, что в коде делается на самом деле. 

Наилучший подход к делу состоит в том, чтобы написать спецификацию до 
разработки, а затем вносить в нее изменения по мере накопления опыта реализации. 
Чем точнее и аккуратнее спецификация, тем больше вероятность, что в результате 
получится работоспособная программа. Даже для программ личного пользования 
бывает полезно подготовить достаточно полное техническое задание, поскольку это 
стимулирует рассматривать возможные альтернативы и фиксировать принятые 
решения. 

Для наших целей нужно иметь спецификацию, содержащую прототипы функций 
и подробные предписания относительно их поведения, обязанностей и сделанных 
предположений: 


поля должны отделяться запятыми; 

поле может заключаться в двойные кавычки ("..."); 

поле в кавычках может содержать запятые, но не символы конца строки; 

поле в кавычках может содержать двойные кавычки, представляемые удвоенны- 
ми символами (""); 

поля могут быть пустыми; пустое поле представляется кавычками ( 
строкой; 

в строках сохраняются пробелы до и после фактических данных; 


) или пустой 


сһаг сѕудеё1іпе (ЕТЬЕ *Ё); 
считывает одну строку из открытого входного файла Е; предполагается, что 
строки исходных данных оканчиваются на \х, \п, \х\п или ЕОЕ; 
возвращает указатель на строку с удаленными завершающими символами, 
или МОЦ, если встретился ЕОЕ; 
строки могут иметь произвольную длину; если превышен лимит памяти, 
возвращается МОШ; 
строка должна восприниматься как объект “только для чтения”; вызываю- 
щий модуль должен сделать ее копию, если необходимо внести изменения 
или сохранить содержимое в другом месте; 
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спаг *сѕуЁҒіе1а(іпё п); 


поля нумеруются начинаяс 0; 

возвращает п-е поле из последней строки, введенной функцией сѕудес1іпе; 
возвращает МОТ: если п < 0 или выходит за пределы последнего поля; 

поля отделяются друг от друга запятыми; 

поля могут быть окружены кавычками ("..."); они удаляются; внутри 
кавычек двойные их символы ("") заменяются одинарными ("), а запятая 
не считается разделителем; 

в полях, не взятых в кавычки, кавычки считаются обычными символами; 

в строке может быть любое количество полей произвольной длины; если 
превышен лимит памяти, возвращается МОТГ; 

поле должно считаться объектом “только для чтения”; вызывающий модуль 
должен сделать его копию, если необходимо внести изменения или сохра- 
нить содержимое в другом месте; 

если функция вызывается до вызова сзудес1іпе, результат не определен; 


106 сѕупЁіе1а (уоіа) ; 
возвращает количество полей в последней строке, считанной функцией 
сѕудеб1іпе; 
если функция вызывается до вызова сѕудес1іпе, результат не определен. 


Эта спецификация все еще оставляет открытыми ряд вопросов. Например, какие 
значения должны возвращать функции сѕуѓіе1а и сѕупЁіе1а, если они вызыва- 
ются после того, как функция сѕудес1іпе встретила символ конца файла (ЕОР)? 
Как следует обрабатывать неправильно сформированные поля данных? Решить с 
ходу все подобные вопросы не так-то просто даже для небольшой программной сис- 
темы, а для большой — практически невозможно, хотя необходимо всеми силами 
пытаться это сделать. Все промахи и недочеты удастся исправить только в ходе реа- 
лизации программы. 

Далее в этом разделе приводится новая реализация функции сѕудес1іпе и всей 
библиотеки. Библиотека разбита на два файла: заголовочный файл сзу.Н, содер- 
жащий объявления функций и представляющий открытый интерфейс библиотеки, 
а также файл реализации су . с, содержащий собственно ее код. Пользователи под- 
ключают файл сѕу.һ к своим программам, а скомпилированный файл сѕу.с ком- 
понуется с программой на этапе редактирования внешних связей. Исходный код 
библиотеки пользователю знать незачем. 

Ниже приведен текст заголовочного файла. 


/* сѕу.һ: интерфейс библиотеки сѕу */ 
ехіегп сһаүр *сзудее11пе(ЕТЬЕ *Ё); /* считывает следующую строку */ 


ехіеүп сһаг *сѕуѓіе1а(іпё п); /* возвращает поле п */ 
ехіегп іпі сѕупҒіе1а (уоіа) ; /* возвращает количество полей */ 


Внутренние переменные, в которых хранится текст, и внутренние функции напо- 
добие ѕр1іє объявлены статическими (с модификатором ѕбабіс), так что они ви- 
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димы только в том файле, который непосредственно их содержит. 
простой способ скрыть информацию в программном модуле на языке С. 


Глава 4 


Это самый 


епот { МОМЕМ = -2 }; /* сигнал нехватки памяти */ 
зсае1с сһаг *11пе = МЫ; /* вводимая строка */ 

ѕіаёсіс сһаг *51іпе = МЈ; /* копия строки для ѕр1іс */ 
ѕбаёсіс іп тахііпе = 0; /* длина 1іпе[(] и ѕ1іпе[] */ 
ѕёабіс сһаг **Ғіе)а = М; /* указатели на поля */ 

ѕёасіс іп тахҒіе1а = 0; /* длина Ғіе1а[] */ 

ѕбабіс іпі пғҒіе1а = 0; /* количество полей в Ёіе1а[] */ 
ѕбасіс сһаг ЁЕ1е1Язер[] = ","; /* символы-разделители полей */ 


Переменные также инициализируются статически. Их инициализированные зна- 
чения используются для проверки того, необходимо ли создавать или расширять 


массивы. 


Данные объявления создают весьма простую структуру данных. Массив 1іпе 
содержит вводимую строку; массив ѕ]1іпе создается путем копирования символов 
из 11пе и вставки маркеров конца строки после каждого поля. Массив Ғіе1а 
содержит указатели на отдельные поля в массиве ѕ1іпе. Ниже на схеме показаны 
эти три массива после ввода и обработки строки ар, "са", "е" "Е", , "д, Һ". 


Затененные элементы в массиве ѕ1іпе не входят в состав полей. 


іле а ь] р [-] [о И М МЕЗЕ Ы -| Е и Ри |.|] 
мн ФЕМ 
Ғіе1а 0 1 2 3 4 


А вот и сама функция сзудек11пе: 


/* сѕудесііпе: ввод строки, по необходимости расширение */ 
/* пробные данные: "10",86.25, "11/4/1998", "2:19РМ", +4.0625 */ 


сһаг *сѕудеб1іпе (ЕТЬЕ *Е1п) 


11: < 
сһаг *пем1, *пемз; 


1Е (1іпе == МОЈ) { /* выделить память при 1-м вызове */ 
тах11пе = тахҒіе1а = 1; 
1іпе = (сһаг *) та11ос (тахііпе); 
ѕ1іпе = (сһаг *) та11ос (тах1іпе); 
Ғіе1а = (сһаг **) та11ос (тахЕ1е1а*517еоЕ (Ғіе1а[0])); 


1Е (1іпе == МОШ, || ѕ1іпе == МОШ, || Ғіе1а == мош) { 


геѕеї (); 
геёџгп МЛ; /* не хватает памяти */ 


} 


Еог (1=0; (с=деес (Ғіп)) !=ЕОР && !епаоЕ11пе (Е1п,с); 1++) { 


1Е (1 >= тах1іпе-1) { /* расширение строки */ 
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пах11пе *= 2; /* удвоение размера */ 
пем1 = (сһаг *) геа11ос (11пе, тах11пе); 
пемѕ = (сһаг *) геа11ос (ѕ1іпе, пах11пе); 
1Е (пем1 == МОШ, || пемѕ == МО) { 

гезее (); 

геіогп МО; /* не хватает памяти */ 
} 


Ііпе = пем1; 
511пе = пемѕ; 


} 


1іпе [1] = с; 
1іпе [1] = '\0'; 
1Е (5ѕр1іб() == МОМЕМ) { 

гезек (); 

геіцгп МО; /* не хватает памяти */ 
геіцгп (с == ЕОЕ && 1 == 0) ? МО : 11ше; 


Введенные данные накапливаются в строке 11пе, которая расширяется по мере 
необходимости путем вызова функции геа11ос. При каждом расширении длина 
этой строки увеличивается вдвое, как в разделе 2.6. Размер массива ѕ1іпе поддер- 
живается таким же, как и 1іпе; функция сѕудеё1іпе вызывает функцию ѕр1іє 
для создания указателей на поля и помещения их в отдельный массив Е1е1а, кото- 
рый также расширяется по мере необходимости. 

По нашему обыкновению мы начинаем работу с очень коротких массивов и рас- 
ширяем их по требованию. Тем самым гарантируется, что код для расширения мас- 
сивов обязательно будет выполняться. Если распределение памяти терпит неудачу, 
вызывается функция гезех, которая восстанавливает глобальные переменные в их 
первоначальном состоянии, так что последующий вызов сѕудес1іпе имеет шанс 
пройти успешно: 


/* гезее: восстановление значений переменных */ 
ѕбаііс уоіа гезеё (уо1а) 


Егее (11пе); /* Егее (МО) разрешено в АМЅІ С */ 
Ғгее (ѕ1іпе); 

Егее (Ғіе1а) ; 

1іпе = МОЦ; 

ѕ1іпе = №; 

Ғіе1а = моц; 

мах11пе = тахЁ1е1а = пЕ1е1а = 0; 


} 


Функция епао#1іпе обрабатывает случаи, когда входная строка заканчивается 
возвратом каретки, символом конца строки, обоими этими символами, или даже ЕОЕ: 


/* епдоЕ11пе: обработка \х, \п, \г\п или ЕОЕ */ 
ѕбабіс іпі епаоЕ11пе(ЕТЬЕ *Е1п, 106 с) 


106 ео1; 


ео мезар ке = 7\5 
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ТЕ (с == '\к') { 
с = дес (Ғіп); 
1Е (с != !'\п' && с != ЕОЕ) 
опдеёс (с, Ёіп); /* лишнее; возвращаем с */ 


геіцгп ео1; 


} 


Отдельная функция подобного рода необходима по той причине, что стандарт- 
ные функции ввода не способны обработать огромное разнообразие форматов, 
встречающихся на практике. 

В нашем прототипе для получения следующей лексемы использовалась функция 
ѕегсок, которая искала в потоке символ-разделитель наподобие запятой. Но ее 
использование стало невозможным из-за потенциального наличия запятых внутри 
кавычек. Поэтому необходимо серьезно изменить реализацию функции ѕр1іб, хотя ее 
интерфейс менять не обязательно. Рассмотрим следующие строки исходных данных: 


ин ин 
ГА 


ии 
, , 


А2 


Каждая из этих строк содержит три пустых поля. Чтобы гарантировать коррект- 
ную обработку таких строк и других подобных данных функцией ѕр1іє, необходи- 
мо значительно усложнить эту функцию. Это тот случай, когда обработка именно 
особых случаев и предельных вариантов начинает доминировать в общем объеме 
программы. 


/* 5р1іє: разбивает строку на поля */ 
ѕбасіс 1106 ѕр1ії (уоіа) 


сҺаг *р, **пемЕЁ; 
сһаг *ѕерр; /* указатель на временный разделитель */ 


іп ѕерс; /* временный символ-разделитель */ 
пҒіе1а = 0; 
1Е (1іпе[0] == '\0') 

геіцгп 0; 


ѕёгсру (ѕ1іпе, 1іпе); 
р = ѕііпе; 


Чо { 
1Е (пЕ1е1а >= тахҒіе1а) { 
тахЁ1е1а *= 2; /* удвоение длины */ 
пемЕ = (сһаг **) геа11ос (Е1е1а, 
пахЁ1е1а * з17еоЕЁ (Ғіе1а[0])); 
1Е (пемЕ == МО) 
геёигп МОМЕМ; 
Ғіе1а = пемЕ; 
} 
ТЕ (*р == 11!) 
зерр = аауацовеа (++р); /* пропуск кавычки */ 
е1зе 


зерр = р + зЕгсврп(р, Е1е1азер); 
зерс = верр[о]; 
ѕерр [0] = '\0!; /* символ конца */ 
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Ғіе1а [п#іе1а++] = р; 


р = зерр + 1; 
} мһііе (зерс == ',!); 


геёцгп пЁ1е1а; 


Вот что происходит в цикле. По мере необходимости наращивается массив указа- 
телей на поля, затем для нахождения и обработки следующего поля вызывается одна 
из двух других функций. Если поле начинается с кавычки, то функция айуаоџобеа 
распознает поле и возвращает указатель на разделитель, который завершает поле. 
В противном случае ищется следующая запятая; для этого используется библиотеч- 
ная функция зегсерл (р, ѕ), которая находит в строке р первое вхождение любого 
символа из строки ѕ. Эта функция возвращает количество пропущенных символов. 

Кавычки внутри поля представляются удвоенными символами кавычек, поэтому 
функция аауацоесеа укорачивает такие символы до одного. Она также удаляет 
кавычки, в которые заключено поле. Некоторую сложность функции придает по- 
пытка корректно справиться с некорректными входными данными, такими как 
"арс"деғ. В подобных случаях мы включаем в состав поля все символы, следую- 
щие за второй кавычкой, пока не встретится корректный символ-разделитель. 
В Місгоѕоѓс Ехсе], по-видимому, используется тот же алгоритм. 

/* аауацоЕеЯ: поле в кавычках; возвращается указатель 


на следующий разделитель */ 
ѕбаёіс сһаг *адуацобеа (сһаг *р) 


{ 


іпе і, 9; 


Бог (і = ј = 0; р[5] 1!= '\01; 1++, ј++) { 
а (р [3] == 11! д& р[++3] = вит) { 
/* копируем до следующего разделителя или \0 */ 
116 К = ѕігсѕрп(р+ј, Е1е1азер); 
пеютоуе (р+1, р+ј, К); 


і += К; 
ј += К; 
ргеак; 
} 
р[1] = р[5]; 
БИ =: А 0; 


геёцгп р + ј; 


} 


Функции сѕуҒіе1а и сэупЕ1е1а тривиальны, поскольку входная строка уже 
разбита на поля к моменту их вызова: 


/* сѕуЁіе1а: возвращает указатель на п-е поле */ 
сһаг *сзуЕ1е1а (116 п) 
{ 
1Е (п < 0 || а >= 0Е1е19) 
геёцгп МЛ; 
геіцгп Ёіе1а [п]; 
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/* сѕупҒіе1а: возвращает количество полей */ 
іп сзупЕ1е1Аа(уо1а) 


геёцгп пЁіе1а; 


} 


Наконец, модифицируем тестирующую программу так, чтобы она работала с 
новой версией библиотеки. Поскольку в новой версии хранится копия введенной 
строки (а в прототипе этого не было), перед выводом полей можно вывести и саму 
исходную строку: 


/* сзуЕезЕ таіп: тестирует библиотеку СЅҮ */ 
іп таіп (уоіа) 

іп 1; 

сһаг *1іпе; 


мһі1е ((1іпе = сѕудеб1іпе (ѕёдіп)) != МОШ) { 
ргіпі# ("1іпе = `%5'\п", 1іпе); 
Ғор (і = 0; 1 < сзупЕ1е1а(); і++) 
ргіпіЁ ("Ғіе1а[%а] = `%3'\п", і, сзуЕ1е1а(1)); 
} 
геёцгп 0; 


} 


На этом наша С-версия библиотеки окончена. Она может обрабатывать входные 
данные произвольной длины и выполняет осмысленные операции даже над некор- 
ректными данными. За это пришлось заплатить вчетверо большей длиной, чем у 
первоначального прототипа, и повышенной сложностью некоторых участков кода. 
Увеличение размеров и сложности — это обычное явление при переходе от пробной 
версии программы к профессиональной. 


Упражнение 4.1. Имеется несколько возможных уровней сложности при реали- 
` зации разбиения полей: можно выделить все поля сразу, но по запросу к конкретно- 
му полю, или же только запрошенное поле, или все поля вплоть до запрошенного. 
Составьте список всех этих возможностей, оцените их преимущества и степень 
сложности, затем реализуйте и сравните быстродействие. 


Упражнение 4.2. Добавьте новые функциональные возможности для того, чтобы 
разделители можно было заменить (а) на произвольный класс символов; (6) на раз- 
личные разделители для различных полей; (в) на регулярные выражения (подробно 
об этом речь пойдет в главе 9). Как должен выглядеть интерфейс в этих случаях? 


Упражнение 4.3. В нашем варианте используется статическая инициализация в 
зависимости от ключевого значения: если указатель на позицию равен МОТ, то вы- 
полняется инициализация. Другой вариант — это потребовать от пользователя вы- 
зывать явную функцию инициализации, в которой можно было бы задавать началь- 
ные длины массивов. Реализуйте версию библиотеки, сочетающую преимущества 
обоих подходов. Какова роль функции гезек в этой реализации? 
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Упражнение 4.4. Спроектируйте и реализуйте библиотеку для создания данных 
в С5У-формате. Простейшая ее версия может принимать массив строк и выводить 
их с кавычками и запятыми. В более совершенной версии могла бы использоваться 
строка формата, аналогичная рг1пЕЕ. Некоторые предложения по системе обозна- 
чений можно найти в главе 9. 


4.4. Реализация на языке С++ 


В этом разделе будет разработана версия библиотеки на языке С++, в которой 
будут учтены некоторые ограничения, присущие С-версии. Вначале мы внесем 
изменения в спецификацию библиотеки, самое важное из которых состоит в замене 
символьных массивов С на строки С++. Использование строкового типа С++ авто- 
матически решит некоторые проблемы управления памятью, поскольку библиотеч- 
ные функции возьмут эту задачу на себя. В частности, функции работы с полями 
будут возвращать строки, доступные для модификации вызывающим модулем. 
Это более гибкая реализация алгоритма, чем предыдущая. 

В классе Сѕу будет определен открытый интерфейс и аккуратно скрыты все 
переменные и функции реализации. Поскольку объект класса содержит все пара- 
метры своего состояния, можно объявлять несколько переменных-экземпляров 
класса Сѕу, независимых друг от друга, и работать с несколькими потоками 
С$У-данных сразу. 


с1азз Сзу { // считывание данных, разделенных запятыми 
// пробные данные: "ГО", 86.25, "11/4/1998", "2:19РМ", +4.0625 


рор1іс: 
Сѕу (1зЕхеам& Ғіп = сіп, з6г1па зер = ",") 
Ғіп(Ғіп), Е1е1азер(зер) {} 


іп деб1іпе (эёгіпа&); 
зЕх1па деёҒіе1а (11% п); 
іп деспҒіе1а() сопзі { гебагп пЕ1е1а; } 


ргіуаѓе: 
іѕёгеат& Е1п; // указатель на входной файл 
ѕігіпа 1іпе; // входная строка 
уесбог<зігіпад> Ғіе1а; // строки-поля 
106 пҒіе1а; // количество полей 
ѕігіпа Ғіе1аѕер; // символы-разделители 
106 эр11е(); 


іп епдоЕ11пе (сваг); 
106 ааур1аіп (сопзЕ з6х1п9& 1іпе, зёг1па& Ё1а, 116); 
іпё аауачовеа (сопзЕ зЕх1па& 1іпе, зігіпах Е1а, 1106); 


}; 


Параметры, заданные по умолчанию для конструктора определены так, чтобы 
объект Сѕу считывал данные из стандартного потока ввода и использовал обычные 
разделители полей. Вместо этих параметров можно явно указать другие. 
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Для работы со строками используются стандартные классы С++ зігіпа и 
уесёог, а не обычные строки в стиле С. У объекта типа зех1иа нет состояния 
“не существует” — если объект пуст, его длина всего-навсего равна нулю. Аналога 
значения МО также не существует, поэтому его нельзя использовать в качестве 
маркера конца файла. В итоге метод Сзу: : деб1іпе возвращает введенную строку 
исходных данных через аргумент по адресу, а возвращаемое значение резервируется 
для сообщений об ошибках и конце файла. 

// аес1іпе: вводит строку, по необходимости расширяя ее 
106 Сѕу: :деб1іпе (з6х1па& з6х) 


{ 


сһаг с; 


Ғор (1іпе = ""; Ғіп.деї (с) && !епаоЕ11пе(с); ) 
Ііпе += с; 

ѕр1іЄ(); 

зү = Ііпе; 

хесихп !ЁҒіп.еоЁ (); 


} 


Знак операции += перегружен таким образом, чтобы добавлять к строке символ. 
Функция епдоЕ1 1пе требует некоторой модификации. И снова придется считы- 


вать символы по одному, поскольку ни одна стандартная функция не может учесть 
все особенности наших входных данных. 


// епдоЕ11пе: обрабатывает \хг, \п, \х\п или ЕОР 
іп Сѕу: :епаоЕ11пе (сһаг с) 


{ 


106 ео1; 
е01 = (с==\ к" ||| с=п"); 
(сов а у 
Ғіп.деї (с); 
1Е (!Ёіп.еоЁ() && с != '\п') 
Ғіп.риёраск (с); // возврат назад 


} 


гесцүп ео1; 


} 


А это новая версия функции ѕр1іє: 


// вр1іёб: разбивает строку на поля 
116 Сѕу::85р1іЄ() 
{ 

зЕх1па Е1а; 

Те, 


пҒіе1а = 0; 
1Е (1іпе.1епдёһ() == 0) 
геіигп 0; 


ао 
1Е (1 < 1іпе.1епаёбһ() && 1іпе[1і] == !"!) 
ј = аауачовея(11пе, Ё1а, ++1); // пропуск кавычки 
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е1 зе 
ј = айур1Іаіп(1іпе, Е1а, і); 
1Е (пЁіе1а >= Е1е1а.512е()) 
Ғіе1а.риѕћһ раск(#1а); 
е1 зе 
Ғіе1а[пғіе1а] = ға; 
пҒіе1а++; 
ЕО 
} мһі1е (3 < 1іпе.1епаёһ()); 


хебаги пѓЁіе1а; 


} 


Поскольку функция зёгсѕрп не работает со строками С++, необходимо внести 
изменения как в ѕр1іє, так и в айуаиооёеа. Новая версия функции аЯдуаио(еа ис- 
пользует стандартную функцию С++ Е1па_Е1кзе_оЕЁ для поиска следующего вхож- 
дения символа-разделителя. При ее вызове в виде ѕ.Ғіпа Ёігѕі оѓ (Ғіе1аѕер, ј) 
в строке ѕ разыскивается первое вхождение любого символа из строки Ғіе1аѕер, 
начиная с позиции ј включительно. Если такое вхождение найти не удается, возвра- 
щается индекс за пределами конца строки, поэтому его нужно вернуть назад в допус- 
тимый диапазон. Во внутреннем цикле Ёог, следующем за этой операцией, символы 
поля накапливаются с помощью переменной Е14 вплоть до достижения символа- 
разделителя. 

// аауачоЕеЯ: обрабатывает поле в кавычках; 


// возвращает индекс следующего разделителя 
106 Сѕу: : аауачовеа (сопѕё эЕх1па& э, эЕх1па& Е1а, 116 і) 


{ 


АН 
ғ1а = "и; 
Рог (ј = і; ј < з.1епаєһ(); ј++) { 
іЁ (= [5] == ("1 && 5 [++]] = ине) { 
116 К = 5.Ёіпа Ғірѕі оѓ (Ғіе1аѕер, ]); 
1Е (К > 5.1епдёһ()) // разделитель не найден 
К = 5.1епдёһ(); 
Бог (К -= ј; К-- > 0; ) 
Е1а += 5[ј++]; 
Ьгеак; 
21а += 8[3]; 
} 
тебатп 9; 


} 


Функция Е1па_Е1гзЕ_оЕЁ также используется в новой функции ааур1а1п, 
которая сдвигает указатель позиции через следующее поле, не заключенное в кавыч- 
ки. Это изменение так же необходимо, как и предыдущие, потому что строковые 
функции С наподобие зехсзрп неприменимы к строкам С++, представляющим 
собой совершенно иной тип данных. 


// айур1аіп: обрабатывает поле без кавычек; 
// возвращает индекс следующего разделителя 
1106 Сѕу::айур1аіп(сопѕї зе х1па& $, ѕігіпд& Е1а, 116 1) 
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106 9; 


ј = 5.Ғіпа Ғігѕ оѓ (Ғіе1аѕер, і); // поиск разделителя 
1Е (3 > 5.1епаёһ ()) // не найден 

ј = 5.1епдіһ(); 
Ғ1а = ѕіёгіпо (5, і, ј-і); 
геёогп ј; 


} 


Как и ранее, функция Сѕу: :дебҒіе1а тривиальна, а Сѕу: :деёпёіе1а вообще 
настолько проста, что определена прямо в объявлении класса. 


// деҒіе1а: возвращает п-е поле 
ѕёгіпа Сѕу::дебҒіе1а(іпі п) 


1Е (п < о || п >= пѓіе1а) 
тебигп ""; 

е1ѕе 
геіогп Ёіе1а[п]; 


Наша тестовая программа представляет собой простейшую вариацию предыдущей: 


// СзуЕезЕ таіп: тестирует класс Сѕу 
106 таіп (уоіа) 


{ 


5Еу1па 1іпе; 


Сѕу су; 
мһі1е (сѕу.деб1іпе (1іпе) != 0) { 
соці << "1іпе = `" << 1іпе <<" '\п"; 
Ғор (іп і = 0; 1 < сѕу.деёпҒіе1а(); і++) 


соці << "Ғіе1а[" << і << "] = 
<< сѕу.дебҒіе10(1) << "'\п"; 


} 


геёигп 0; 


} 


Способ использования этой библиотеки несколько отличается от версии на языке 
С, хотя и незначительно. В зависимости от компилятора версия на С++ может рабо- 
тать медленнее как на 40%, так и в четыре раза, если входные данные имеют боль- 
шой объем наподобие 30 000 строк с 25 полями на строку. Как мы уже говорили в 
связи с программой тагкоу, эти вариации в быстродействии отражают качество 
реализации библиотеки. Исходный текст программы на С++ примерно на 20% коро- 
че, чем на С. 


Упражнение 4.9. Усовершенствуйте реализацию на языке С++, перегрузив знак 
операции []. Эта операция должна давать возможность обращаться к полям через 
выражения типа сѕу [і]. 


Упражнение 4.6. Напишите библиотеку СЗУ на языке Јауа, а затем сравните три 
реализации по их доступности в понимании, надежности и быстродействию. 


Упражнение 4.7. Переоформите версию библиотеки СЗУ на языке С++ в виде 
шаблона ЅТІ. 


Раздел 4.5 Принципы интерфейса 125 


Упражнение 4.8. Версия библиотеки на С++ позволяет нескольким независимым 
экземплярам Сѕу работать параллельно без взаимного вмешательства. Это достига- 
ется тем, что все параметры состояния инкапсулируются в одном объекте, и таких 
объектов можно создавать сколько угодно. Измените С-версию библиотеки так, что- 
бы это стало возможно и в ней, заменив глобальные структуры данных на динамиче- 
ски размещаемые в памяти и инициализируемые явной функцией сзупем. 


4.5. Принципы интерфейса 


В предыдущих разделах мы занимались проработкой деталей интерфейса — под- 
робно определенной и описанной границы между кодом, обеспечивающим предос- 
тавление определенных услуг, и кодом, в котором эти услуги используются. Интер- 
фейс определяет, что тот или иной модуль кода должен делать для пользователя, как 
его функции и (иногда) элементы данных могут использоваться остальными частя- 
ми программы. В нашем интерфейсе СЗУ определены три функции — считывание 
строки, получение поля и возвращение количества полей. Других операций пользо- 
ватель выполнить не сможет. 

Чтобы иметь успех, интерфейс должен хорошо подходить для той работы, кото- 
рую он делает, т.е. быть простым, общим, стандартизированным, предсказуемым, 
надежным в работе. Кроме того, он должен легко адаптироваться к другим пользова- 
телям и изменениям внутренней реализации. В хороших интерфейсах соблюдается 
ряд принципов. Система этих принципов не является полностью согласованной, 
а сами они не вполне независимы, но с их помощью можно более-менее описать, что 
и как должно происходить на границе между двумя модулями кода. 


Скрывайте подробности реализации. Реализация, стоящая за интерфейсом, 
должна быть скрыта от остальных частей программы так, чтобы ее изменение не по- 
влияло ни на что за ее пределами. Этот организационный принцип известен под 
многими именами: сокрытие информации, инкапсуляция, абстрагирование, модуля- 
ризация и т.д. Все это разные названия для одной и той же идеи. Интерфейс должен 
скрывать детали реализации, несущественные для клиента (пользователя). Невиди- 
мые подробности можно легко изменить — например, для того, чтобы расширить 
область действия интерфейса, сделать его более эффективным или вообще заменить 
всю реализацию полностью. | 

Стандартные библиотеки большинства языков программирования представляют 
собой хорошо знакомые примеры этого подхода, хотя они и не всегда идеально спро- 
ектированы. Стандартная библиотека ввода-вывода С — одна из самых известных и 
наилучших. Она состоит из двух-трех десятков функций для открытия, закрытия, 
чтения, записи и других операций с файлами. Реализация подробностей файлового 
ввода-вывода скрыта в структурном типе ЕТЬЕ*, свойства которого можно посмот- 
реть (он объявлен в файле <ѕбаіо.һ»>), но не стоит трогать. 

Если в заголовочном файле нет подробного объявления структуры, а только ее 
имя, то такой тип часто называют скрытым (орадие), потому что его свойства неви- 
димы, а все операции выполняются через указатель на какой-то реальный объект. 
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Избегайте глобальных переменных. Везде, где это возможно, передавайте ссылки 
на все данные через аргументы. 

Мы решительно настроены против открытости или общедоступности данных в 
любой форме — слишком уж сложно поддерживать корректную последовательность 
обработки данных, если дать пользователю право изменять переменные по его ус- 
мотрению. Интерфейсы функций облегчают задачу ограничения доступа, но тем не 
менее данный принцип часто нарушается. Стандартные потоки ввода-вывода напо- 
добие зе а1п и зЕаоиЕ почти всегда определены как элементы глобального массива 
структур типа ЕІІЕ: 


ехіегп ЕТЬЕ __ фо [_МЕТЬЕ]; 
#аеЕ1пе зЕЯ1п (&__106[0]) 
#аеЕ1пе зЕдочЕ (& іоЫ[1]) 
#аеЕ1пе зЕЧеххг (& іоЫ[2]) 


Эти объявления делают реализацию насквозь видимой. Становится также ясно, 
что нельзя присваивать какие-либо значения идентификаторам зЕ91п, Е ое и 
зЕаехкх, хотя они внешне и похожи на имена переменных. Примечательное имя 
___фоф следует соглашению стандарта АМЗГ С о том, что все закрытые имена реали- 
зации, видимые снаружи, должны начинаться с двух знаков подчеркивания. 
Это снижает вероятность конфликта имен. 

Классы в С++ и Јауа представляют собой гораздо лучшие механизмы сокрытия 
информации. Понимать их суть очень важно для правильного программирования на 
этих языках. Классы-контейнеры стандартной библиотеки шаблонов ЭТ. в языке 
С++ заходят в своем следовании принципу еще дальше: кроме некоторых гарантий 
быстродействия, никакой другой информации о реализации нет вообще, и разработ- 
чики библиотеки могут использовать любой механизм по своему выбору. 


Выберите небольшой набор непересекающихся примитивов. Интерфейс дол- 
жен предоставлять столько функциональных возможностей, сколько необходимо, но 
не более того, и функции не должны пересекаться в выполняемых ими задачах. 
Имея в библиотеке много функций, ее можно сделать более удобной для использо- 
вания — все, что пользователь пожелает, будет всегда под рукой. Но большой ин- 
терфейс труднее реализовывать и дорабатывать, и из-за его размера может оказаться 
невозможным сколько-нибудь плодотворно изучить и использовать такой интер- 
фейс. “Интерфейсы разработки приложений”, или АРІ, иногда имеют такие огром- 
ные размеры, что нормальному человеку не стоит и надеяться их освоить. 

В целях удобства некоторые интерфейсы предлагают несколько способов сделать 
одно и то же. Это тенденция, которой следует избегать. Стандартная библиотека 
ввода-вывода С содержит по меньшей мере четыре разные функции для записи 
одного символа в поток вывода: 

сһаг с; 

раёс (с, Ёр); 

Ерис (с, Ёр); 

Ғрүіпі# (Ёр, "%с", с); 

Емгісе (&с, з12еоЕЁ(срахг), 1, Ёр); 


Если поток вывода представляет собой зЕ ол, то есть еще несколько возможно- 
стей. Все они удобны, но отнюдь не необходимы. 
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Интерфейсы небольшого объема предпочтительнее, чем большие, — по крайней 
мере, до тех пор, пока не будет убедительно доказана недостаточность имеющихся 
функций. Сделайте что-то одно, но сделайте это хорошо. Не добавляйте в интерфейс 
что-либо только потому, что это можно сделать, и не занимайтесь исправлением ин- 
терфейса, если ошибка кроется в реализации. Например, вместо двух функций -- 
быстрой тетсру и безопасной теттоуе — стоило бы иметь одну, всегда надежную и 
при этом достаточно быструю во всех ситуациях, когда это возможно. 


Не делайте ничего за спиной пользователя. Библиотечная функция не должна 
записывать секретных файлов или переменных, а также изменять глобальные дан- 
ные. Кроме того, ей следует быть крайне осторожной с модификацией данных в вы- 
зывающем модуле. А вот функция зЕхеоК нарушает сразу несколько из этих требо- 
ваний. Неприятно удивляет тот факт, что она записывает нулевые байты в середину 
строки ее исходных данных. То, что функция использует нулевой байт для обозна- 
чения места окончания предыдущей операции, подразумевает хранение неких сек- 
ретных данных между ее вызовами, а это потенциальный источник ошибок и пре- 
пятствие к параллельной работе нескольких экземпляров функции. Лучше было бы 
включить в библиотеку одну функцию для разбиения входной строки на лексемы. 
По аналогичным причинам вторая С-версия нашей библиотеки не может использо- 
ваться с двумя входными потоками (см. упражнение 4.8). 

При работе с одним интерфейсом нельзя требовать подключения другого просто 
потому, что так удобнее разработчику. Вместо этого следует делать интерфейсы са- 
модостаточными, а если это невозможно, то хотя бы информировать пользователя с 
предельной ясностью, какие еще требуются внешние функциональные возможности. 
В противном случае бремя технической поддержки и доработки интерфейса ложит- 
ся на клиента. Очевидный пример — это тяжкая необходимость включать длинные 
списки заголовочных файлов в код на языках С и С++; заголовочные файлы могут 
содержать тысячи строк и подключать еще десятки других заголовочных файлов. 


Выполняйте одну и ту же операцию везде одинаковым способом. Очень важ- 
но соблюдать согласованность и единообразие. Аналогичные задачи должны выпол- 
няться аналогичными средствами. Библиотечные функции С из семейства зїг... 
очень просты в использовании даже без документации, потому что все они устроены 
примерно одинаково: данные передаются справа налево, т.е. в том же направлении, 
что и при присваивании, и все функции возвращают результирующую строку. А вот 
в стандартной библиотеке ввода-вывода С трудно предсказать порядок аргументов 
при вызове функций. В некоторых аргумент типа ЕТЬЕ* стоит первым, в некото- 
рых — последним; размер и количество элементов передаются в какой угодно после- 
довательности. В противоположность этому, алгоритмы контейнеров ТІ. обеспечи- 
вают весьма единообразный интерфейс, так что становится легко пользоваться даже 
новой или малознакомой функцией. 

Следует добиваться не только внутренней согласованности, но и внешней, т.е. ста- 
раться, чтобы функциональные средства использовались по определенному стандарту. 
Например, функции тет... из библиотеки С были разработаны после функций 
зЕг..., но заимствовали их стиль. Способ использования стандартных функций вво- 
да-вывода Ёгеад и Емх1 ее было бы легче запомнить, если бы он совпадал с использо- 
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ванием функций геаа и мгісе, на которых они основаны. Ключи командной строки 
Опіх начинаются со знака “минус”, но любой конкретный буквенный ключ может 
означать совершенно разные вещи даже в близкородственных программах. 

Если шаблоны подстановки наподобие * в *.ехе раскрываются системным 
командным интерпретатором, то операции выполняются единообразно. Если же это 
делается индивидуально прикладными программами, то возможны вариации. 
В \"еБ-браузерах требуется один щелчок мышью для перехода по гиперссылке, но в 
других приложениях для активизации программы или перехода по ссылке использу- 
ется двойной щелчок. В результате многие люди автоматически щелкают дважды. 

Перечисленным принципам легче следовать в одной среде и труднее в другой, 
но все же они сохраняют свое значение везде. Например, скрыть подробности реали- 
зации в языке С трудно, но хороший программист постарается их не афишировать, 
чтобы закрытая информация не стала частью интерфейса и не нарушила принцип 
сокрытия данных. Комментарии в заголовочных файлах, имена особого формата 
(например, __1оЪ) и т.д. — все это помогает поощрять хороший стиль програм- 
мирования там, где не удается заставить пользователя следовать ему. 

Несмотря на все это, наши способности по усовершенствованию интерфейсов все 
же имеют границы. Даже наилучшие интерфейсы сегодняшнего дня могут породить 
проблемы с наступлением дня завтрашнего. И все же именно хорошее проектиро- 
вание интерфейсов помогает оттянуть этот зловещий “завтрашний день”. 


4.6. Управление ресурсами 


Одна из наиболее сложных проблем при разработке интерфейса библиотеки (а также 
класса или пакета) — это управление ресурсами, которыми библиотека владеет либо 
единолично, либо совместно с вызывающими модулями. Самый очевидный из таких 
ресурсов — это память, относительно которой всегда возникает вопрос, кто должен ее 
распределять и освобождать. Но есть и другие важные ресурсы совместного пользования, 
такие как открытые файлы и общие переменные. Вкратце говоря, связанные с этим про- 
блемы подразделяются на категории проблем инициализации, хранения состояния, 
совместного обращения и копирования, а также очистки или удаления. 

В прототипе нашего пакета СЗУ используется статическая инициализация указа- 
телей, счетчиков и т.п. Но это ограничивает наши возможности, поскольку делает не- 
возможным возврат в первоначальное состояние и запуск библиотеки заново после 
вызова хотя бы одной функции. Альтернативный подход здесь таков — определить 
функцию инициализации, устанавливающую все внутренние переменные в коррект- 
ное исходное состояние. Это позволяет начать операции с начала, но требует от поль- 
зователя вызывать функцию инициализации явным образом. Как раз для этой цели 
функцию гезе* во второй версии библиотеки можно было бы сделать открытой. 

В языках С++ и ]ауа для инициализации полей данных в классах используются 
конструкторы. Хорошо определенные конструкторы гарантируют, что все данные 
инициализированы и нет никакого способа создать неинициализированный объект 
класса. Для поддержки различных видов инициализации объявляется группа конст- 
рукторов. Например, в класс Сѕу можно было бы включить один конструктор, кото- 
рый в качестве аргумента принимает имя файла, а другой — поток ввода. 
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А как насчет копирования информации, которой владеет и управляет библиотека, 
например, входных строк и их полей? Наша С-версия программы сѕучеб1іпе пре- 
доставляет прямой доступ к входным строкам (как к самой строке, так и кее полям), 
возвращая указатели. Этот неограниченный доступ имеет ряд недостатков. Вполне 
возможно, что пользователь затрет участок памяти и сделает часть данных непри- 
годными. Возьмем следующий оператор: 


зЕхсру (сѕуҒіе1а (1), сѕуЁіе1а (2)); 


Эта конструкция может натворить бед разными способами, например, затереть 
начало поля №2, если второе поле длиннее первого. Пользователю библиотеки при- 
дется делать копию информации, которую он хотел бы сохранить, в промежутке 
между вызовами сѕуде1іпе. В следующем фрагменте кода указатель вполне 
может стать некорректным, если при втором вызове сзудеб1іпе произойдет пере- 
распределение памяти для строкового буфера: 


сһаг *р; 


сѕудеі1іпе (Ёіп); 
р = сзуЕ1е1а (1); 
сзудеё1іпе (Ё1п); 
/* здесь р может стать некорректным */ 


Версия на С++ безопаснее, поскольку копируются такие строки, которые можно 
изменять как угодно. 

В ]ауа для обращения к объектам используются ссылки; объект — это любые 
данные с общим именем, кроме элементов простых типов наподобие іпє. Это более 
эффективно, чем копирование, но кто-нибудь может впасть в заблуждение, что 
ссылка — это и есть копия. У нас уже была такая ошибка в одной из ранних версий 
программы тагКкоу на ]ауа. (В языке С это вообще вечный источник проблем со 
строками символов.) Методы-клоны предоставляют возможность делать копии по 
мере необходимости. 

Противоположностью инициализации или конструированию объектов служит их 
уничтожение, или ликвидация, — очистка данных и возвращение ресурсов в систему 
после того, как объект больше не нужен. Это особенно важно в отношении памяти, 
поскольку программа, забывающая о необходимости освобождать память, в конце 
концов страдает от ее нехватки. Многие современные программы склонны вести 
себя подобным образом. Аналогичные проблемы возникают с закрытием открытых 
файлов: если данные буферизуются, то для буфера может требоваться очистка (а для 
памяти — возвращение в систему). В стандартных библиотечных функциях С очист- 
ка буфера происходит автоматически при нормальном завершении программы. 
Случай аварийного завершения необходимо программировать особо. Стандартная 
функция С и С++ с именем абехіє позволяет получить управление в свои руки не- 
посредственно перед нормальным завершением программы. Разработчики реализа- 
ций интерфейсов могут воспользоваться этим средством для выполнения операций 
по очистке и удалению объектов. 
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Освобождайте ресурс на том же уровне, на котором он запрашивался. Один 
из подходов к управлению размещением и освобождением ресурса заключается в 
том, чтобы его уничтожением ведала та же библиотека, пакет или интерфейс, кото- 
рые отвечают за распределение памяти для него. Другая формулировка этого подхо- 
да такова — интерфейс не должен изменять статус существования ресурса так, чтобы 
это было заметно снаружи. Наши С$У-библиотеки считывают данные из файлов, 
которые уже были открыты ранее, и оставляют их открытыми после завершения 
операций. Пусть модуль, вызывающий библиотеку, сам закрывает свои файлы. 

Конструкторы и деструкторы С++ очень помогают следовать этому принципу. 
При выходе экземпляра класса за пределы его области действия или при его прину- 
дительном уничтожении автоматически вызывается деструктор. В деструкторе 
можно очищать буферы, возвращать память в систему, переустанавливать значения 
переменных состояния и делать все, что еще может оказаться необходимым. В ]ауа 
аналогичного механизма нет. Хотя для класса Јауа можно определить метод ликви- 
дации, нет никакой гарантии, что он вообще будет выполняться, не говоря уже о том, 
чтобы он выполнялся когда нужно. Поэтому очистку нельзя гарантировать, хотя 
иногда полезно бывает предположить, что она все-таки выполняется. 

И все же в ]ауа существуют удобные средства, сильно облегчающие управление 
памятью. Это встроенные средства сборки мусора (ватаре сойесноп). По мере вы- 
полнения программы она размещает в памяти все новые объекты. Удалить их явным 
образом невозможно, однако исполнительная система следит за тем, какие объекты 
используются, а какие — уже нет, и периодически возвращает неиспользуемые объ- 
екты в пул свободной памяти. 

В деле сборки мусора существует целый ряд подходов и приемов. В некоторых 
схемах подсчитывается количество обращений к каждому объекту из модулей — 
ведется его счетчик ссылок. Объект освобождается тогда, когда его счетчик ссылок 
становится равным нулю. Эту технику можно запрограммировать в Си С++ явным 
образом для управления объектами общего пользования. В других методах периоди- 
чески отслеживается путь от пула размещенных в памяти объектов ко всем объек- 
там, на которые имеются ссылки. Объекты, для которых этот путь прослежен, счи- 
таются используемыми, тогда как объекты, на которые не ссылаются никакие 
другие, полагаются неиспользуемыми и могут быть освобождены. 

Существование автоматической сборки мусора вовсе не означает, что при проек- 
тировании и реализации интерфейса не будет никаких проблем с распределением 
памяти. По-прежнему необходимо определить, должны ли интерфейсы возвращать 
ссылки на совместно используемые объекты или их копии, и все это существенно 
влияет на поведение программы. Сборка мусора не обходится даром — необходимо 
где-то хранить служебную информацию и как-то востребовать назад память; к тому 
же сборка мусора выполняется в непредсказуемые моменты времени. 

Все эти проблемы становятся еще сложнее, если библиотека должна использо- 
ваться в среде, где несколько потоков могут одновременно вызывать ее функции, как 
это делается в многопоточных программах на ]ауа. 

Во избежание проблем необходимо писать реентерабельный код, т.е. такой, кото- 
рый работает корректно независимо от количества одновременно вызванных моду- 
лей. В реентерабельном коде нет ни глобальных переменных, ни статических 
локальных переменных, и вообще любых переменных, которые могут модифициро- 
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ваться в то время, пока ими пользуется другой поток. Ключ к хорошему многопо- 
точному программированию лежит в таком разделении компонентов, при котором 
они взаимодействуют только через четко определенные интерфейсы. Библиотеки, 
которые неосторожно предоставляют переменные в общее пользование, наносят 
смертельный удар по этой модели. (В многопоточной программе функция зЕХЕОК — 
это настоящее стихийное бедствие, как и все функции из библиотеки С, которые 
хранят данные во внутренних статических переменных.) Если уж так необходимо 
отдавать переменные в общее пользование, то их необходимо снабдить каким-то 
механизмом захвата и блокирования, чтобы гарантировать единовременное обраще- 
ние со стороны только одного потока. Классы оказывают в этом деле существенную 
помощь, поскольку позволяют реализовать удобные модели совместного использо- 
вания и блокирования доступа. Синхронизированные методы в Јауа позволяют од- 
ному потоку блокировать целый класс или экземпляр класса от одновременного 
модифицирования другим классом; механизм синхронизированных блоков позволя- 
ет только одному потоку за раз выполнять тот или иной фрагмент кода. 

Короче говоря, необходимость многопоточной обработки данных добавляет 
сложностей программисту, и это слишком большая тема, чтобы сколько-нибудь под- 
робно обсуждать ее здесь. 


4.7. Обработка ошибок 


В предыдущих главах для обработки ошибок использовались такие функции, как 
ерх1пЕЕ или езЕ гор. В случае ошибки они выводят на экран сообщение и завер- 
шают выполнение программы. Например, функция ергіпі# делает все то же самое, 
что и Ере1тЕЕ (ѕёӢегг,...), но в случае ошибки выводит сообщение о ней и 
завершает программу, возвращая в систему код ошибки. В ее работе используются 
заголовочный файл <5Е9ака.в> и библиотечная функция УЕрх1пЕЕ; с их помо- 
щью на экран выводятся аргументы, представленные в прототипе многоточием (...). 
Библиотеку ѕсдагд необходимо инициализировать вызовом функции уа ѕбагё, 
азавершить ее работу следует вызовом уа епа. В главе9 будут представлены 
дополнительные примеры работы с этим интерфейсом. 

#1пс1аае <зЕЧаха.В> 


#іпс1џае <з6к1па.В> 
#1пс1аае <еггпо.һ> 


/* ерх1пЕЕ: выводит сообщение об ошибке и выходит */ 
уоіа ергіпіғ (свак *Еше, ...) 


\Уа_1156 агаз; 


ЕЕТазь (369016); 
ЇЕ (ргодпате () != М) 
Ғрүіпё# (з6аегк, "%5: ", ргодпате ()); 


уа загі (агаз, Ёт); 
УЕрк1п ЕЕ (ѕзідӢегг, Ёт, аказ); 
уа епа (агаз); 
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1Е (Ет [0] != '\0' && Ещё [зех1ел (ЁтЕ-1)] == ':') 
Еру1пЕЕ (56 4егхг, " %5", ѕігеггог (еггпо)); 

Ғргіпё# (з6аехк, "\п"); 

ех1е (2); /* условный код аварийного выхода */ 


Если строка формата заканчивается двоеточием, то функция ерг1пЕЁ вызывает 
стандартную функцию С зе геггохг, которая возвращает строку с имеющейся в сис- 
теме дополнительной информацией о возникшей ошибке. Мы также написали 
функцию мерг1п ЕЕ, аналогичную ергіпі#, которая отображает предупреждение, 
но не завершает работу программы. Интерфейс, аналогичный рг1пЕЕ, удобен для 
конструирования строк, которые могут посылаться на печать или отображаться в 
диалоговых окнах. 

Аналогичным образом, функция езЕх@ир пытается создать копию строки, 
а затем выходит с выводом сообщения (для чего служит функция ергіпі#), если 
произошла ошибка распределения памяти: 


/* езегаар: создает копию строки, сообщает об ошибке */ 
сһаг *езекаир (сһаг *5) 


{ 


срах *(; 
Е = (саг *) ма1]ос (ѕіг1еп(5) +1); 
ТЕ (6 == МЈ) 


ерх1пЕЕ ("еѕсгаир (\"%.203\") Ғаі1еа:", в); 
ѕЕгсру (Е, 8); 
геёигп Ё; 


} 


Функция ета11ос делает то же самое при распределении памяти с помощью 
ма11ос: 


/* ета11ос: вызывает та11ос, сообщает об ошибке */ 
уоіа *ета11ос (512е_6 п); 


{ 


уоіа *р; 


р = та11ос (п); 
1Е (р == Ш) 

ергіпіҒ ("та11ос ої? %иа руёеѕ Еа11еа:", п); 
гесигп р; 


} 


Все эти функции объявляются в одном заголовочном файле с именем ергіпё# .П: 


/* ергіпіҒ.Һ: функции, сообщающие об ошибках */ 


ехёегп уоіа ергіпё# (сһагр *, ...); 
ехёегп уоіа мергіпе# (сһаг *, ...); 
ехсеүп сһаг хеѕёгаир (сһаг *); 

ехбеүп уоіа *ета11ос (ѕіле Е); 

ехбегп уоіа хегеа11ос (уоіа *, ѕіле Е); 
ехёегп сһаг хргодпате (уоіа); 


ехіеүп уоіа ѕесргодпате (сһаг *); 
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Этот заголовочный файл должен подключаться к любому файлу кода, в котором 
вызывается одна из перечисленных функций. Каждое сообщение об ошибке также 
может включать имя программы, если этого потребует вызывающий модуль. Имя 
устанавливается или извлекается тривиальными функциями ѕебргодпате и 
ргодпате, объявленными в заголовочном файле и определенными в исходном коде 
модуля вместе с ерх1пЕЁ: 


ѕёаёіс сһаг *паше = М); /* имя программы для сообщений */ 


/* весргодпате: устанавливает заданное имя программы */ 
уоіа ѕесргодпате (сһаг *ѕіг) 


{ 
} 


/* ргодпате: возвращает хранимое имя программы */ 
сһаг *ргодпате (\о1а) 


{ 
} 


Типичное использование этих функций выглядит таким образом: 


пате = езегацр (зё); 


гесигп папе; 


116 таіп(іпё акас, сһаг *аүду[]) 


ѕеіргодпате ("тагкоу") ; 


Е = Ёореп (арду [1], "г"); 
ЇЁ (Ё == МО) 
ергіпё# ("сап'Е ореп %5:", аүду [1]); 


} 


В результате выводится примерно следующее: 


пагкоу: сап'Е ореп рѕаїт.ёхі: Мо ѕисһ Е11е ог аігесіогу 


Эти вспомогательные функции оказались очень удобными при программирова- 
нии некоторых наших задач, поскольку они унифицируют обработку ошибок, и само 
существование таких функций стимулирует скорее перехватывать ошибку, чем иг- 
норировать ее. Тем не менее в них нет ничего особенного, и читатель может предпо- 
честь вместо них какие-нибудь другие. 

Предположим, что нам требуется не просто написать несколько функций для 
своего собственного употребления, а сформировать библиотеку для передачи дру- 
гим пользователям. Что должна делать функция в такой библиотеке, если случается 
непоправимая ошибка? Функции, приведенные ранее в этой главе, выводили на 
экран сообщение об ошибке и завершали программу аварийно. Это вполне подходит 
для многих программ, особенно небольших утилит и автономных приложений. 
Но во многих случаях такой образ действий окажется неправильным, поскольку 
не даст другим модулям программы шанса исправить положение. Например, тексто- 
вый редактор должен попытаться не потерять информацию из редактируемого до- 
кумента. В некоторых ситуациях библиотечная функция не должна даже выводить 
сообщение, потому что программа вполне может выполняться в среде, где такое со- 
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общение исказило бы выходные данные или просто пропало без следа. Разумный 
вариант — это выводить диагностические сообщения В файл-протокол, который 
можно читать независимо от других данных. 


Перехватывайте ошибки на низком уровне, обрабатывайте их на высоком. 
Общий принцип гласит, что ошибки следует перехватывать на как можно более низ- 
ком системном уровне, а вот обрабатывать их — на высоком. В большинстве случаев 
решать, что делать в связи с ошибкой, должен вызывающий, а не вызываемый мо- 
дуль. Библиотечные функции могут помочь в этом, завершая ошибочную операцию 
корректно и неаварийно. Рассуждая таким образом, в случае несуществующего поля 
данных лучше возвращать МОТ, чем завершать программу аварийно. Аналогично, 
функция суздее11пе возвращает МОЦ, каждый раз независимо от того, сколько раз 
ее вызвали после обнаружения конца файла. 

Надлежащие возвращаемые значения не всегда легко определить, как мы уже ви- 
дели ранее при обсуждении вопроса о том, что должна возвращать функция 
сѕудес1іпе. Хотелось бы возвращать как можно больше полезной информации, 
причем в такой форме, какую легко было бы использовать в других модулях про- 
граммы. В языках С, С++ и Јаха это означает возвращение некоего кодового значе- 
ния оператором гесиогп, а фактических данных — по адресам (ссылкам) через аргу- 
менты. Во многих библиотечных функциях есть способ отличить возвращаемый 
нормальный результат от ошибочного. Так, функция ввода дессһаг возвращает 
элемент типа сһаг в случае успеха и некоторое несимвольное значение типа ЕОҒ в 
случае конца файла или другой ошибки. 

Этот механизм не срабатывает, если возможные корректные данные заполняют 
весь диапазон возвращаемых функцией значений. Например, математическая функция 
вычисления алгоритма 109 может возвращать любое вещественное значение. В биб- 
лиотеке вещественной арифметики ТЕЕЕ для индикации ошибки служит специальное 
значение Мам (“поё а питфег” — “не число”), которое и возвращается в таких случаях. 

В некоторых языках, например Рег! или Тсі, имеются ненакладные способы орга- 
низации групп из двух или более значений, именуемых кортежами (ѓиріеѕ). В таких 
языках значение функции и сигнал ошибки можно легко возвратить вместе. В биб- 
лиотеке ЅТІ. языка С++ есть тип данных ра1х, которым также можно воспользо- 
ваться в этих целях. 

Было бы желательно отличать друг от друга различные исключительные состояния 
наподобие конца файла и др., а не сваливать их все в одну кучу и огульно называть 
“ошибками”. Если это трудно, можно ограничиться возвратом одного “исключитель- 
ного” результата, но определить еще одну функцию, которая бы по требованию выда- 
вала более подробную информацию о последней случившейся ошибке. 

Именно такой подход принят в системе Чшх и стандартной библиотеке С, в ко- 
торой многие системные вызовы и библиотечные функции возвращают -1, а также 
помещают специфический код ошибки в глобальную переменную еггпо. Функция 
зегегкох служит для возврата строкового сообщения, ассоциированного с кодом 
ошибки. Рассмотрим следующую программу: 

#1пс1аае <ѕбаіо.Һ> 


#1пс1а4е <зігіпа.Һ> 
#1пс]1аае <еггпо.һҺ»> 
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#1пс1аЯе <таёһ.Һ> 


/* еххпо таіп: тестирует еггпо */ 
106 таіп (уоіа) 


доцріе Ё; 


еххпо = 0; /* сброс кода ошибки */ 

Е = 109(-1.23); 

ре1пЕЁЕ("%Е #а %5\п", ЁҒ, егхпо, ѕігеггоү (еггпо)); 
геёцгп 0; 


} 


В нашей системе она вывела следующее сообщение: 


пап0х10000000 33 Юротаіп еггог 


Как показано выше, вначале переменную еггпо необходимо очистить (сделать 
равной нулю); затем в случае ошибки она получает ненулевое значение. 


Используйте исключительные ситуации для действительно исключитель- 
ных случаев. В некоторых языках для перехвата необычных ситуаций и принятия 
мер существует механизм исключительных ситуаций. Если случается ошибка, вы- 
полнение программы направляется по альтернативному пути. Исключительные 
ситуации не следует использовать для работы с ожидаемыми, нормальными значе- 
ниями данных. Например, чтение данных из файла в конце концов приведет к тому, 
что встретится его конец. Эту ситуацию следует обрабатывать нормально, с приме- 
нением возвращаемого из функции кода, а не перехвата исключительной ситуации. 

В языке Јауа пишут так: 


бегіпа Епаме = "ѕзотеЕі1емате"; 
Еу} 
Еі1еІприєбёегеат іп = пем Е1]еТприббегеам (Ёпаме); 
іп с; 
мһі1е ((с = 1п.хеаа()) != -1) 
Ѕузѕзсет. оце .ргіпё ( (сһагр) с); 
іп.с1оѕе(); 


} саёсһ (Рі1еМобҒЕоцпӣЕхсерііоп е) { 
буѕёет.егг.ргіпё1іп(Ғпате + " по ЁҒоџцпа"); 
} саёсһ (ІОЕхсербіоп е) { 
Ѕуѕёет.егг.ргіпё1п ("ІОЕхсерііоп: " + е); 
е.ргіпёбіёасктТгасе (); 


В этом фрагменте кода в цикле считываются символы, пока не встретится конец 
файла. Сигнал об этом событии — возвращение значения -1 из функции геаа. Но если 
файл не открывается, то возникает исключительная ситуация. В языках С и С++ 
в этом случае с входным потоком был бы ассоциирован указатель по11. Наконец, если 
в блоке гу случается еще какая-нибудь ошибка ввода-вывода, то снова возникает 
исключительная ситуация, которая обрабатывается в блоке ТОЕхсерЕ1 оп. 

Исключительными ситуациями часто злоупотребляют. Из-за их способности 
изменять ход выполнения программы часто возникают весьма извилистые конст- 
рукции, сильно подверженные ошибкам. Неудача при открытии файла — это не 
очень-то экстраординарное событие; генерирование исключительной ситуации для 
такого случая выглядит слишком сильной мерой. Исключительные ситуации лучше 
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приберечь для действительно непредсказуемых событий типа переполнения файло- 
вых систем или ошибок вещественной арифметики. 

В программах на С с помощью пары функций зе  ) тр и 1опајтр можно органи- 
зовать низкоуровневую системную базу для построения механизма исключительных 
ситуаций. Но эти функции достаточно сложны в применении, так что мы не будем 
здесь вдаваться в подробности. 

А как насчет восстановления ресурсов в случае ошибки? Должна ли библиотека 
пытаться восстановить ресурсы, если случается ошибка? Обычно не должна, но она 
может оказать услугу другим модулям, постаравшись оставить после себя информа- 
цию в настолько корректном и безопасном состоянии, насколько это возможно. 
Гарантированно неиспользуемая память должна вернуться в систему. Если какие-то 
переменные остаются доступными программе, их значения следует сделать коррект- 
ными. Обычным источником ошибок является обращение к указателю, который 
ссылается на освобожденную память. А вот если обработчик ошибок после освобож- 
дения памяти обнулит указатели, ссылающиеся на нее, то такое обращение не оста- 
нется незамеченным. Функция гезее во второй версии библиотеки СЗУ как раз 
реализовала попытку решения этих проблем. В целом нужно стремиться к тому, чтобы 
после случившейся ошибки библиотека осталась в работоспособном состоянии. 


4.8. Пользовательские интерфейсы 


До сих пор мы говорили об интерфейсах между компонентами одной программы 
или между программами. Но существует еще один важный интерфейс — между про- 
граммой и ее пользователем-человеком. 

Большинство примеров программ в этой книге снабжено довольно простыми 
консольно-текстовыми интерфейсами. Как говорилось в предыдущем разделе, необ- 
ходимо стремиться к тому, чтобы распознавать ошибки, выводить сообщения о них и 
пытаться восстановить нормальный ход операций. Сообщения об ошибках должны 
содержать всю имеющуюся информацию о них и быть как можно более понятными 
без контекста. Например, следующее сообщение невразумительно: 


еѕегаир Ғаі1еа 


На самом деле ему положено выглядеть так: 


пагкоу: еѕбгаицр ("Регх1Аа") Ғаі1ей: Метоку 11116 геасһеа 


Добавить эту дополнительную информацию в сообщение ничего не стоит, а поль- 
зователю от этого может быть большая польза при поиске источника ошибки или 
корректировке исходных данных. 

В случае необходимости программы должны сообщать пользователю, как их пра- 
вильно запускать. Это делается примерно такими функциями: 


/* ичзаде: выводит инструкцию и завершает программу */ 
уоіа изаче (уоіа) 
{ 
Ере1пЕЕ (ѕсаегг, "иѕаде: %5 [-а] [-п пмогаѕ]" 
" [-5= взееа] [Е11ез ...]\п", ргодпате()); 
ех1е (2); 
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Имя программы указывает на источник сообщения, что особенно важно при 
работе с большим программным процессом. Если же программа выдает сообщение 
типа “синтаксическая ошибка” или “ошибка в такой-то функции”, то пользователь 
может вообще не понять, откуда это сообщение пришло. 

В тексте сообщений об ошибках, командных приглашений, диалоговых окон 
должна содержаться информация о правильной форме исходных данных. Не пиши- 
те, что параметр слишком велик, — сообщите допустимый диапазон значений. 
Там, где это возможно, сам текст сообщения должен представлять собой корректные 
исходные данные — например, полную командную строку с правильными аргумен- 
тами. Кроме того, что такие сообщения направляют пользователя, они еще позволя- 
ют скопировать данные в файл или буфер обмена для повторного запуска процесса. 
Отсюда виден недостаток диалоговых окон: их содержимое плохо поддается копи- 
рованию и сохранению для последующего использования. 

Один из эффективных способов организации хорошего пользовательского ин- 
терфейса состоит в том, чтобы разработать специализированный язык для задания 
параметров, выполнения операций и т.п. Хорошая система обозначений помогает 
сделать программу легкой в использовании, а также способствует ее качественной 
реализации. Интерфейсы на основе специализированных языков рассматриваются в 
главе 9. 

Очень важно программировать безопасно и устойчиво — так, чтобы программа 
была неуязвимой по отношению к любым некорректным входным данным. Это важ- 
но и с позиций системной безопасности, и для защиты пользователя от самого себя. 
Более подробно этот вопрос рассматривается в главе 6, посвященной тестированию. 

Для большинства людей при слове “интерфейс” перед глазами возникает графи- 
ческий интерфейс пользователя, характерный для современных компьютеров. 
Графические интерфейсы — это отдельная огромная тема для обсуждения, поэтому 
здесь мы скажем всего несколько слов. Во-первых, графические интерфейсы очень 
трудно разрабатывать и доводить до безупречно надежного состояния, поскольку их 
работа сильно зависит от поведения и желаний человека. Во-вторых, если у системы 
есть пользовательский интерфейс, то именно операции по его обслуживанию 
составляют большую часть кода, тогда как сами алгоритмы обработки данных зани- 
мают сравнительно скромный объем. 

И тем не менее вышеизложенные принципы применимы как к внешнему дизайну 
программ, так и к внутренним реализациям пользовательских интерфейсов. Если 
подходить с позиций пользователя, то все качества хорошего стиля программирова- 
ния, такие как простота, понятность, стандартизация, единообразие, идиоматич- 
ность, модульность, — это всего лишь шаги на пути к хорошему и легкому в приме- 
нении интерфейсу. Отсутствие этих качеств обычно порождает неудобные в работе 
и неуклюжие интерфейсы. 

В частности, весьма желательны единообразие и стандартизация интерфейса. 
Под этим подразумевается единая система понятий, единиц измерения, форматов, 
макетов, шрифтов, цветов, размеров и всех прочих характеристик, присущих графи- 
ческой системе. Например, сколько разных слов следует использовать в англоязыч- 
ной программе для обозначения команды выхода из программы или закрытия окна? 
Их существует полтора десятка— от АБапаов до <С]+7> включительно. 
Даже знаток английского языка может запутаться, не говоря уже об иностранце. 
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В графических системах интерфейсы играют особую роль, поскольку такие сис- 
темы обычно велики, сложны в реализации и управляются совершенно другой мо- 
делью ввода данных, отличной от последовательного считывания текста. Велико- 
лепно проявили себя при программировании графических интерфейсов объектно- 
ориентированные языки, поскольку в них есть способы инкапсулировать в одном 
объекте состояние и возможные операции окна и т.п., а также собрать общие черты 
элементов интерфейса в базовых классах, вынеся отличия между ними в производ- 
ные классы. 


Дополнительная литература 


Несмотря на устаревшие технические детали, книгу Етейегіск Р. Вгоо$, ]т., 
Тре Муса! Мап Мопіёћ (Аайіѕоп-№еѕ]еу, 1975; Аппіуегѕагу Ейійоп 1995) по-преж- 
нему стоит читать; она содержит взгляды на разработку программного обеспечения, 
в той же мере ценные сегодня, как и во время ее первого издания. 

Практически в каждой книге по программированию найдется какая-нибудь по- 
лезная информация о разработке интерфейсов. Одна из книг, ]орп Г.аКоз, Гағе-5саіе 
С++ 5ойшаге Оеят (АЧАзоп-\Уе$еу, 1996), основана на приобретенном тяжкими 
трудами опыте и посвящена вопросам проектирования и реализации очень больших 
программ на С++. Хорошим изложением аналогичных вопросов по программирова- 
нию на С является книга Юауіа Напѕоп, С Гпѓеғўасеѕ апа Ітріетепіаёопѕ (Аайіѕоп- 
М/езеу, 1997). 

Превосходное описание групповой разработки программ с подчеркиванием важ- 
ной роли чернового прототипирования дано в книге Ѕќеуе МсСоппе|, Рара 
ГРеоеіортепі (Мисгозой Ргеѕѕ, 1996). 

Имеется несколько интересных книг по разработке графических пользователь- 
ских интерфейсов, написанных с самых разных позиций. Мы предлагаем следующие 
источники из их числа: 

Кеуіп Мше, Оагге] Ѕапо, Юеѕівпіпа Узиа Іпіегјасеѕ: Соттипісайоп Опешеа 
Тесћпідиеѕ (Ргепасе На] 1995). 

Веп Ѕһпеійегтап, Юеѕіртіпв Тре Оѕеғ Іпіетјасе: 5іғаіеріеѕ јог Ејјесіое Нитап- 
Сотриіѓеғ Гпіеғасіоп (Зга ейібоп, Айаіѕоп-№еѕ]еу, 1997). 

А]ап Соорег, Ароиѓ Расе: Тһе Еѕѕепіаіѕ оў Оѕеғ Гпіетўасе Оеяет (ТОС, 1995). 

Наго!а ТћтЫеру, Оѕеғ пиегГасе Оеяет (Айаіѕоп-Ұеѕеу, 1990). 


Отладка 


Бир. 

Ь. Дефект или изъян в машине, плане и т.п. Досл. “насекомое, клоп”. 
Происх. америк. 

Ра] Ма| Сах., 11 марта 1889 г., 1/1. Г-н Эдисон, по его словам, не сомкнул 
глаз две прошлые ночи, разыскивая “клопа” (“Бид”) в своем фонографе. 
Данное выражение обозначает поиск неисправности; этим как бы подра- 
зумевается, что некое воображаемое насекомое спряталось внутри машины 
и является источником проблемы. 


Оксфордский словарь английского языка, 2-е изд. 
(ОхГота Епвіѕһћ Глснопату) 


В предыдущих четырех главах мы представили на суд читателя большой объем 
кода и при этом притворились, что все приведенные программы и функции зарабо- 
тали с первого же запуска. Конечно же, это не так — ошибок возникало достаточно 
много. Слово “Бир” (“клоп”), употребляемое в программировании для обозначения 
ошибки, родилось не в среде программистов, а гораздо раньше, и тем не менее имен- 
но в этой индустрии оно является одним из самых распространенных. Так в каких 
же щелях программ прячутся эти “клопы”? 

Общая причина ошибок состоит в разнообразии способов, с помощью которых мо- 
гут взаимодействовать компоненты программ. Поскольку программы состоят именно 
из компонентов и взаимодействия между ними, это увеличивает сложность системы и 
повышает вероятность ошибок. Создано множество методов для ограничения взаимо- 
действия компонентов, чтобы информация передавалась в программе по как можно 
меньшему количеству каналов. Среди таких методов — сокрытие данных, абстрагиро- 
вание, деление на интерфейс и реализацию, различные специфические языковые сред- 
ства. Существуют также методы для контроля целостности и согласованности про- 
граммных архитектур — анализ спецификаций, формализованные процедуры верифи- 
кации, различные техники моделирования. Но все это не затронуло фундаментальные 
основы индустрии разработки программ; сколько-нибудь принципиальное отличие 
видно только на примере небольших задач. Реальность такова, что ошибки есть и бу- 
дут; их обнаруживают тестированием, а устраняют отладкой. 

Хорошие программисты знают, что на отладку уходит столько же времени, 
сколько и на написание кода, поэтому они стараются учиться на своих ошибках. 
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Каждая найденная ошибка научит вас либо не делать ее снова, либо обнаружить ее в 
кратчайшие сроки, если она все-таки случится. 

Отладка — дело нелегкое, и отнимает она непредсказуемое количество времени. 
Поэтому следует поставить перед собой такую цель — тратить на отладку как можно 
меньше времени. Для этого есть ряд методов и подходов: качественное проектирова- 
ние, хороший стиль, проверка граничных условий и предельных случаев, вставка 
контрольных условий в код, стремление к устойчивости по отношению к входным 
данным, хорошо определенные интерфейсы, минимальное использование глобаль- 
ных данных, привлечение средств диагностики. Как известно, профилактика обхо- 
дится гораздо дешевле лечения. 

Какова роль языка программирования во всем этом? Главная движущая сила в 
развитии языков программирования — это как раз стремление предотвратить воз- 
можность ошибки средствами самих языков. Некоторые средства и свойства языков 
действительно делают определенные классы ошибок гораздо менее вероятными. 
Ктаким средствам относится контроль диапазона индексов массивов, ограниченное 
использование указателей или вообще отказ от них, сборка мусора, специальные 
строковые типы данных, типизированный ввод-вывод, строгие требования к соот- 
ветствию типов. Есть и такие средства, которые особенно сильно провоцируют воз- 
никновение ошибок. Это оператор добо, глобальные переменные, неконтролируе- 
мые указатели, автоматические преобразования типов. Программистам следует 
знать слабые или рискованные места своих языков и соблюдать особую осторож- 
ность при их применении. Необходимо также включать все проверки, поддерживае- 
мые компилятором, и обращать внимание на все предупреждения. 

Каждое средство, предотвращающее возможность той или иной ошибки, имеет 
свою цену. Если, например, язык высокого уровня не позволяет сделать простую 
низкоуровневую ошибку, это означает, что в нем можно наделать ошибок более вы- 
сокого уровня. Никакой язык не может гарантировать отсутствия ошибок. 

Как бы мы ни протестовали против такой перспективы, большая часть времени 
программистов все равно уходит на тестирование и отладку. В этой главе рассмат- 
ривается вопрос о том, как сделать процесс отладки как можно короче и продуктив- 
нее. К тестированию мы вернемся в главе 6. 


5.1. Отладчики 


Компиляторы основных языков программирования обычно поставляются вместе 
с многофункциональными отладчиками, нередко в виде единой среды разработки, в 
которой интегрируются все операции по созданию и редактированию исходного 
кода, компиляции, выполнению и отладке. Отладчики часто имеют графический 
интерфейс для пошагового выполнения операторов или функций программы; они 
способны приостанавливать выполнение на заданных строках или при выполнении 
заданного условия. В них также имеются средства форматирования и отображения 
значений переменных. 

Отладчик можно активизировать непосредственно тогда, когда становится оче- 
видным наличие проблемы. Некоторые отладчики берут власть в свои руки в тот 
момент, когда при выполнении программы происходит что-то неожиданное. Обычно 
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бывает нетрудно выяснить, в каком месте прервалось выполнение программы, 
проследить последовательность активных в тот момент функций (стековый фрейм) 
и отобразить значения локальных и глобальных переменных. Этой информации 
может оказаться вполне достаточно для обнаружения ошибки. Если же это не так, то 
с помощью точек останова и пошагового выполнения можно выполнить аварийную 
программу в отладочном режиме и найти место первого проявления проблемы. 

В подходящей среде и в руках квалифицированного программиста хороший 
отладчик может сделать отладку быстрой и эффективной, а то и вовсе тривиальной. 
Если существуют такие мощные инструменты отладки, зачем кому-нибудь понадо- 
бится обходиться без них? Чего ради, спросит читатель, мы написали целую главу, 
посвященную отладке? 

Для этого имеется ряд причин. Некоторые из них вполне объективны, а другие 
основаны на нашем личном опыте. Некоторые языки, не относящиеся к числу 
наиболее распространенных, не имеют отладчиков или предоставляют только 
зачаточные возможности отладки. Отладчики привязаны к операционной системе, 
поэтому при переходе из одной среды в другую можно не найти знакомого 
отладчика. Некоторые программы плохо поддаются отладке с помощью отладчика; 
среди таковых — многопоточные приложения, Параллельные процессы, операцион- 
ные системы, распределенные сетевые системы. Все эти классы программ часто 
приходится отлаживать на более низком уровне, и в этом случае вы остаетесь 
наедине с программой без всякой помощи, кроме разве что дополнительных опе- 
раторов вывода, вооруженные только своим опытом и навыками анализа кода. 

На наш собственный вкус, отладчики лучше использовать только для получения 
стекового фрейма и значений одной-двух переменных. Одна из причин нашей 
нелюбви к отладчикам состоит в том, что бывает очень легко заблудиться в 
подробностях сложных структур данных и управляющих конструкций. Пошаговое 
выполнение программы, по нашему мнению, менее продуктивно, чем тщательное ее 
обдумывание и добавление операторов вывода или дополнительных проверок в 
критических местах кода. Перебор всех операторов по очереди отнимает болыше 
времени, чем просмотр результатов хорошо продуманного отладочного вывода. 
Можно гораздо быстрее решить, куда вставить дополнительную проверку или 
контрольный вывод, чем “дошагать” до критического фрагмента кода, даже зная, где 
он находится. Что еще более важно, контрольные операторы остаются в тексте 
программы, а сеансы отладки неизбежно заканчиваются. 

“Слепое зондирование” с помощью отладчика далеко не всегда бывает продук- 
тивным. Гораздо полезнее выяснить с помощью отладчика, в каком состоянии 
находилась программа в момент аварийного завершения, а затем подумать, как это 
состояние могло наступить. Пользоваться отладчиками нелегко, и их поведение 
часто ставит в тупик. Начинающим программистам они вообще скорее помеха, чем 
подспорье. Если вы задали отладчику неправильный вопрос, он, вероятнее всего, 
что-то ответит, но эта информация может завести вас в дебри. 

И все же отладчики могут принести огромную пользу, поэтому такой инструмент 
следует держать наготове в своем арсенале. Часто в случае возникновения ошибки 
именно он первым приходит на помощь. Но если у вас нет отладчика или вы 
застряли на особенно сложной проблеме, прибегните к методам и подходам, 
изложенным далее в этой главе, и убедитесь, что в любом случае отладку можно 
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выполнить быстро и эффективно. Эти подходы помогут также и при работе с 
отладчиком, поскольку касаются общих принципов того, как разобраться в ошибках 
и их вероятных причинах. 


5.2. Простые ошибки с очевидными 
симптомами 


Оп-ля! Случилась ошибка. Программа завершилась аварийно, или вывела на экран 
какую-то нелепицу, или же зациклилась и выполняется без остановки. Что же делать? 

Новички склонны обвинять в ошибке компилятор, библиотеки и вообще все, что 
угодно, кроме их собственного кода. Опытным программистам тоже хотелось бы так 
думать, но они не строят иллюзий и знают, что большинство проблем они создают 
себе сами. | 

К счастью, большинство ошибок достаточно просты и могут быть обнаружены 
простыми методами. Внимательно прочтите полученные на выходе ошибочные дан- 
ные и проанализируйте, как они могли быть сгенерированы. Просмотрите отладоч- 
ные выходные данные, выведенные непосредственно перед аварийным завершени- 
ем; если возможно, получите стековый фрейм с помощью отладчика. Теперь вам уже 
известно кое-что о том, что именно случилось и где. Сделайте паузу и подумайте. 
Как это могло случиться? Мысленно проследите ход работы программы назад от 
места ее аварии, выдвигая предположения о возможной причине. 

Отладка программы, подобно раскрытию преступления, всегда подразумевает 
дедуктивное рассуждение. Случилось нечто невероятное, и единственная достовер- 
ная информация об этом — сам факт, что оно произошло. Поэтому необходимо ду- 
мать в обратном направлении от события, чтобы попытаться понять его причины. 
Имея исчерпывающее объяснение, мы будем знать, какие меры принять. Заодно, 
скорее всего, выяснится еще пара вещей, которых мы сами не ожидали обнаружить. 


Ищите знакомые конструкции. Спросите себя, знакома ли вам та или иная про- 
граммная конструкция. Мысль “где-то я это уже видел” представляет собой первый 
шаг к пониманию, а иногда и дает нужный ответ. Самые распространенные ошибки 
имеют свои неповторимые проявления. Например, начинающие программисты на С 
часто пишут так: 


? 116 п; 
? зсапЕ ("%а", п); 


Это неправильно. Необходимо писать так: 


116 п; 
ѕсапї ("%а", &п); 


В результате этой ошибки, как правило, предпринимается попытка обращения к 
недоступному участку памяти. Преподаватели языка С распознают симптомы этой 
ошибки мгновенно. 
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Бесконечным источником простых ошибок является несоответствие типов и их 
преобразование в функциях ру1п ЕЕ и зсапЕ: 
Аб. =. 


? аоиџр1е а = РТ; 
? ргіпе# ("%а %#\п", а, п); 


Симптомом этой ошибки часто является вывод на экран нелепых значений пере- 
менных: огромных целых чисел, нереально маленьких или больших вещественных. 
В системе Ѕип ЗРАКС эта программа выдала одно большое число и одно — просто 
астрономическое (чтобы оно поместилось на страницу, пришлось разбить его на не- 
сколько строк): 

1074340347 268156158598852001534108794260233396350\ 
1936585971793218047714963795307788611480564140\ 


0796821289594743537151163524101175474084764156\ 
422771408323839623430144.000000 


Еще одна распространенная ошибка — это употребление спецификации %# вме- 
СТО %1Е для ввода чисел типа доцр1е с помощью функции зсапЕ. Некоторые ком- 
пиляторы распознают такие ошибки, проверяя соответствие между типами аргумен- 
тов ргіпё# и эсапЕЁ и соответствующими спецификациями в строках формата. 
Если активизировать все предупреждающие сообщения, то для такого вызова 
ре1пеЕ, какой бы показан выше, компилятор асс выведет на экран следующее: 


:9: магп1па: іп Ёогтас, доџріе ага (агч 2) 
:9: магпіпа: доцџріе Еогтае, даіЁѓегепі Суре агч (ага 3) 


х.с 
х.с 
Характерные ошибки возникают также, если не ‘инициализировать локальную 
переменную. В результате можно получить очень большое число — “мусор”, остав- 
шийся в данной ячейке памяти от предыдущих переменных. Некоторые компилято- 
ры предупреждают о подобных ситуациях, но для этого часто приходится включать 
специальную проверку при компиляции, и все равно некоторые случаи ускользают 
от внимания компилятора. Участки памяти, выделенные функциями та11ос, 
геа11ос и т.п., также часто содержат “мусор”. Не забывайте инициализировать 
такие буферы памяти. 


Начните проверку с последнего изменения. Итак, какое же последнее измене- 
ние вы внесли в программу? Если по мере доработки программы вы вносили посте- 
пенные изменения, по одному за раз, то либо источник ошибки находится в новом 
фрагменте кода, либо новый код способствует ее проявлению. Чтобы локализовать 
проблему, тщательно проанализируйте последние изменения. Если в новой версии 
ошибка есть, а в старой — нет, следовательно, новый код имеет отношение к пробле- 
ме. Это означает, что нужно как минимум всегда хранить предыдущую версию про- 
граммы, в правильности которой вы более или менее уверены, чтобы было с чем 
сравнивать. Необходимо также вести учет сделанных изменений и исправленных 
ошибок, чтобы не пришлось заново разыскивать эту жизненно важную информа- 
цию, одновременно пытаясь решить проблему. Здесь существенную помощь могут 
оказать различные механизмы фиксации истории изменений, такие как системы 
управления версиями. 
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Не делайте одну и ту же ошибку дважды. После исправления ошибки задайте 
себе вопрос, не могли ли вы сделать такую же в другом месте. Именно это случилось 
с одним из авторов за несколько дней до написания этой главы. Программа пред- 
ставляла собой черновой прототип для коллеги и содержала шаблонную конструк- 
цию для обработки необязательных аргументов-ключей: 


? Бог (і = 1; і < акас; 1++) { 

2 1Е (ахау[1] [0] != '-') /* ключи закончились */ 
? ргеак; 

? зміёсһ (агау [1] [1]) { 

? сазе 'о': /* выходной файл */ 
? оцбпаше = акау[1]; 

? ргеак; 

? саѕе '!Ё'!: 

? Ғүгот = або1 (ага\у[1]); 

? ргеак; 

? сазе '6': 

? Со = або] (агду [1]); 

? ргеак; 

? 


Как только наш коллега испробовал эту программу, он сообщил, что имя выход- 
ного файла результатов неизменно получало префикс -о. Это было неприятно, 
но легко поправимо; следовало лишь написать так: 


оцёпате = &акау [1] [2]; 


Исправление было внесено, и программа снова отправлена на выполнение. 
Тут же пришел ответ, что программе не удается корректно обработать такой аргу- 
мент, как -Е123; преобразованное из строки в число значение всегда равнялось 
нулю. Это ошибка того же типа; следующий блок сазе в операторе ѕмієсћ должен 
был выглядеть так: 


Ғүгот = або] (хака [1] [2]); 


Поскольку автор работал в спешке, он не заметил, что та же самая ошибка попа- 
далась еще в двух местах, так что потребовалось дополнительное время на исправле- 
ние всех принципиально схожих ошибок. 

В несложных фрагментах кода ошибки появляются тогда, когда мы теряем бди- 
тельность из-за излишне знакомых конструкций. Даже если код настолько прост, 
что его, казалось бы, можно писать во сне, все равно не делайте этого — держите гла- 
за широко открытыми. 


Не откладывайте отладку. Торопливость создает проблемы во многих ситуа- 
циях. Не игнорируйте аварийное завершение программы — проанализируйте его 
причины немедленно, потому что позже оно может и не случиться, а потом будет 
слишком поздно. В качестве знаменитого примера можно привести проект “Магз 
Раф Ёпаег”. После безупречного приземления на Марсе в июле 1997 года компьюте- 
ры этого автоматического космического корабля начали перезагружаться каждые 
один-два дня, что совершенно озадачило инженеров. Проанализировав источник 
проблемы, они вдруг поняли, что уже встречались с ней раньше. Такие перезагрузки 
случались и в предполетных испытаниях, но их попросту игнорировали, потому что 
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велись более важные работы над другими проблемами. Итак, решение задачи было 
отложено на более позднее время, а когда это время наступило, компьютеры уже на- 
ходились за десятки миллионов километров от Земли, и отладка стала, мягко говоря, 
затруднительной. 


Анализируйте стековый фрейм. Хотя с помощью отладчиков можно успешно 
следить за выполняющейся программой, наиболее полезное их применение — 
это изучение состояния программы после ее аварийного завершения. Самой полез- 
ной частью выдаваемой отладчиком информации можно считать номер строки, 
на которой программа прекратила работу; этот номер часто фигурирует в стековом 
фрейме. Большим подспорьем служат также ошибочные значения данных програм- 
мы (нулевые указатели; огромные целые числа, которым следовало бы быть малень- 
кими, или отрицательные числа, которым полагалось быть положительными; неал- 
фавитные символы). 

Приведем типичный пример, основываясь на нашей теме сортировки из главы 2. 
Чтобы отсортировать массив целых чисел, следует вызвать функцию азоге, передав 
в нее функцию сравнения целых чисел істр: 


іпё агг [№]; 
дѕогі (агг, М, 312е0Е (агг [0]), істр); 


А теперь представим себе, что в эту функцию случайно передали имя функции 
сравнения строк ѕстр: 


? іпё агг [№]; 
? азогЕ (агг, М, 312еоЕ (агг [0]), зстр); 


В данном случае компилятор не сможет распознать никакого несоответствия ти- 
пов, так что крах неизбежен. При выполнении программы происходит ее аварийное 
завершение, поскольку она делает попытку обратиться к адресу памяти, защищен- 
ному от доступа. Отладчик арх дает следующий стековый фрейм (текст отформати- 
рован для удобства): 

0 ѕігстр (0х1а2, 0х1с2) ["ѕСгстр.5":31] 

1 ѕстр(р1 = 0х10001048, р2 = 0х1000105с) ["Баааз.с":13] 

2 ахі (0х10001048, 0х10001074, 0х400620, 0х4) ["азохе.с":147] 
3 аѕоге (0х10001048, 0х1с2, 0х4, 0х400р20) ["азохе.с": 63] 

4 таіп() ["раддѕ.с":45] 

5 __іѕсаге() ["сгб1біпіє.5":13] 


Отсюда видно, что программа потерпела крах при выполнении функции ѕёгстр. 
Анализ значений аргументов показывает, что два указателя, переданные в ѕёгстр, 
слишком малы, а это верный признак ошибки. Стековый фрейм содержит последо- 
вательность номеров строк, в которых вызывались функции. Строка 13 в файле 
Баааз . с соответствует следующему вызову: 


гесигп зігстр(у1, у2); 


Очевидно, именно этот вызов оказался аварийным, так что отсюда и следует 
исходить при поисках ошибки. 
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С помощью отладчика можно также получить значения глобальных или 
локальных переменных в определенный момент, что также помогает при выяснении 
обстоятельств аварии. 


Сначала читайте, потом исправляйте. Эффективный, хотя и недооцененный 
способ отладки — это тщательный анализ кода и его глубокое обдумывание до 
внесения каких-либо исправлений. При появлении ошибки у программиста 
неизменно рождается могучий порыв броситься к клавиатуре и начать исправлять 
программу, чтобы ошибка поскорее исчезла. Но вполне возможно, что он попросту 
не понимает истинной природы ошибки и исправит что-нибудь не то, в результате 
наделав новых ошибок. Чтобы взглянуть на код под другим углом, чем на экране 
компьютера, распечатайте критический фрагмент программы на бумаге. К тому же 
это поощряет думать над кодом медленнее и тщательнее. И все же не нужно делать 
из распечатки культа. Может получиться так, что загубив уйму бумаги, вы потом 
попросту не сможете как следует проанализировать структуру программы, 
разбросанную по множеству страниц. Кроме того, выведенный на печать листинг 
программы устареет в тот самый момент, когда вы начнете вносить исправления. 

Если ничего не получается, сделайте перерыв. Иногда вы видите в исходном коде 
не то, что там написано, а то, что вам хотелось бы видеть. Перерыв даст вам 
возможность успокоиться и вернуть себе объективность в восприятии кода. Итак, 
сопротивляйтесь искушению немедленно что-то набирать; разумная альтернатива — 
это как следует подумать над кодом. 


Объясните код кому-то другому. Объяснение своего исходного кода кому-то 
другому — это очень эффективный метод. По сути, чаще всего вы объясняете его 
себе самому. Иногда требуется всего лишь несколько фраз, после которых вас 
осеняет догадка, и остается только сказать коллеге: “ОЙ, я уже все понял. Извини за 
беспокойство”. Этот подход исключительно эффективен даже тогда, когда слуша- 
тель не является программистом. В одном из университетских вычислительных 
центров недалеко от рабочего стола консультанта восседал плюшевый медведь. 
Студенты, озадаченные таинственными ошибками в своих программах, обязаны 
были сперва поведать свои беды медведю, и только после этого им разрешалось 
обратиться за советом к преподавателю. 


5.3. Сложные ошибки с трудными 
симптомами 


“Ничего не понятно. Что же делать?” Если при анализе ошибки у вас возникает 
только эта мысль, значит, жизнь всерьез зашла в тупик. 


Сделайте ошибку воспроизводимой. Первый шаг к решению — это заставить 
ошибку проявляться по своему желанию. Нет ничего хуже, чем гоняться за ошибкой, 
которая еще и проявляется не всякий раз. Потратьте некоторое время и сконструи- 
руйте такие входные данные и наборы параметров, которые гарантированно будут 
вызывать проблему к жизни. Затем оформите запуск программы так, чтобы его 
можно было выполнять щелчком на кнопке или несколькими нажатиями клавиш. 
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Если ошибка действительно серьезна, вам придется прогонять ее в процессе отладки 
снова и снова, а значит, необходимо иметь удобный способ делать это. 

Если ошибку не удается проявить каждый раз по своему желанию, подумайте, 
почему это так. Какой набор условий заставляет ее появляться чаще — хотя бы с 
большей вероятностью, — чем остальные? Даже если не удается увидеть ошибку 
каждый раз, все же можно сэкономить много времени, сократив срок ее ожидания. 

Если программа может выдавать отладочные выходные данные, активизируйте эту 
возможность. Очень желательно, чтобы модельные программы наподобие алгоритма 
генерирования текста по марковским цепям (см. главу 3) предоставляли отладочную 
информацию по требованию программиста. Это может быть, например, инициали- 
затор датчика случайных чисел, по которому можно восстановить генерируемые 
выходные данные. Также желательно, чтобы и сам инициализатор можно было 
изменить по мере необходимости. Подобные возможности есть во многих программах, 
и вваши собственные также стоит включить аналогичные средства. 


Применяйте подход “разделяй и властвуй”. Подумайте, можно ли сделать 
концентрированную “выжимку” входных данных, из-за которых программа завер- 
шается аварийно. Сузьте круг подозрений, построив минимально возможный набор 
исходных данных из тех, которые вызывают ошибку к жизни. Выясните, какие 
изменения в этих данных заставляют ошибку исчезнуть. Попытайтесь найти как 
можно более точные тестовые примеры для проявления ошибки. Каждый тестовый 
пример должен давать определенный результат, который подтверждает или 
отпровергает ту или иную гипотезу относительно природы ошибки. 

Затем примените поиск методом деления пополам. Отбросьте половину входных 
данных и посмотрите, по-прежнему ли на выходе получается ошибочный результат. 
Если нет, то вернитесь к предыдущему состоянию и отбросьте другую половину 
данных. Та же процедура применима и к самому тексту программы: уберите часть 
программы, которая предположительно не имеет отношения к ошибке, и проверьте, 
не исчезла ли ошибка. Для фрагментирования больших тестовых данных и текстов 
программ без потери ошибки удобно пользоваться редактором с командой отмены 
последней операции (Опао). 


Анализируйте числовые закономерности, присущие ошибкам. Иногда удается 
сузить поле исследований, заметив определенную закономерность в статистических 
параметрах данных, которые вызвали ошибку. Например, мы с удивлением обнару- 
жили несколько орфографических ошибок в одном из свеженаписанных разделов 
этой книги. Некоторые буквы попросту исчезли из текста. Это поставило нас в 
тупик. Текст создавался путем копирования и вставки фрагментов из другого файла, 
поэтому естественно было предположить, что ошибка кроется в реализации команд 
для вырезания и вставки в текстовом редакторе. Но с чего начать поиск проблемы? 
Мы поискали подсказку в самом тексте, и нам показалось, что пропущенные 
символы довольно равномерно разбросаны по тексту. Мы измерили интервалы 
между ними и обнаружили, что расстояние между соседними пропущенными 
символами составляло в точности 1023 байта. Это число слишком знакомо выгля- 
дит, чтобы быть случайным. Поиск чисел, близких к 1024, в исходном коде 
редактора дал несколько потенциально ошибочных мест. Одно из них находилось в 
новом, недавно добавленном коде; мы проверили его первым и легко обнаружили 
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классическую ошибку пропуска одной позиции — нулевой байт, т.е. символ конца 
строки, затирал последний значащий символ в 1024-символьном буфере. 

Итак, изучение числовых характеристик выходных данных вывело нас прямо на 
ошибку. Сколько это заняло времени? Пару минут мы пребывали в озадаченном 
состоянии, потом минут пять искали закономерность в расположении пропущенных 
символов, минуту-другую разыскивали потенциально ошибочные места в коде 
редактора и еще минуту устраняли саму ошибку. Нечего было и надеяться проделать 
это с помощью отладчика, поскольку в работе участвовали две многозадачные 
программы, управляемые командами мыши и обменивающиеся данными через 
файловую систему. 


Выводите побольше данных на экран, чтобы локализовать поиск. Если 
толком непонятно, что делает программа, добавьте в нее операторы вывода, чтобы 
она отображала побольше данных. Это один из самых простых методов отладки, 
требующий минимальных трудозатрат. Вставляйте операторы так, чтобы проверять 
свое понимание работы программы или уточнять гипотезы о природе ошибок. 
Например, если вы уверены, что в какое-то место программы управление попасть не 
должно, вставьте в него оператор для вывода сообщения типа “сюда попасть нельзя”. 
Если это сообщение появится на экране, передвиньте оператор назад по тексту 
программы, чтобы выяснить, в каком же месте события приняли неожиданный 
оборот. Или же сделайте наоборот: расставьте сообщения вида “выполняется то”, 
“выполняется это” последовательно по тексту программы, чтобы потом обнаружить, 
в каком месте программа еще работала нормально. Каждое сообщение должно быть 
характерным, чтобы их легко можно было различать. 

Выводите сообщения в компактной фиксированной форме, чтобы легко распо- 
знавать их на глаз или с помощью программ наподобие чгер — средств поиска 
заданных образцов в текстах. (Иметь такую программу, как агер, при работе с тек- 
стами просто необходимо. В главе 9 приведена одна из простых реализаций подоб- 
ного алгоритма.) Если отображается значение переменной, то формат всякий раз 
должен быть одним и тем же. В языках С и С++ следует выводить указатели в виде 
шестнадцатеричных чисел по спецификации %х или %р; таким образом можно уви- 
деть, равны ли между собой (или соотносятся иным образом) те или иные указатели. 
Научитесь правильно читать значения указателей, различать правдоподобные и 
неправдоподобные их значения типа нуля, отрицательных, нечетных или слишком 
малых чисел. Знакомство с формой представления адресов также пригодится при 
работе с отладчиком. 

Если программа имеет тенденцию выводить слишком много данных, может ока- 
заться достаточным выводить контрольные сообщения о прохождении тех или иных 
точек программы в виде всего одной буквы: А, В, С ит.д. 


Пишите код с самопроверкой. Если требуется более подробная информация, 
напишите свою собственную функцию для проверки того или иного условия, кон- 
трольного вывода значений переменных и аварийного завершения программы: 


/* спеск: проверка условия, контрольный вывод, завершение */ 
уоіа сһескК (сһаг *з) 


1Е (уаг1 > уаг2) { 
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ргіпеЁ ("%5: уагі %А уаг2 %А\п", в, уаг1, уаг2); 
ҒЕ1цѕһ (ѕіаӢоці); /* завершаем операции вывода */ 
арогі (); /* сигнализируем аварийное завершение * / 


} 


Мы написали функцию сһеск, чтобы с ее помощью вызывать функцию арог+ из 
стандартной библиотеки С, которая вызывает аварийное завершение выполнения 
программы для последующего анализа при помощи отладчика. В каком-нибудь дру- 
гом случае, возможно, понадобится продолжить выполнение программы после вы- 
вода контрольных данных. 

Функцию сһеск или ей подобную следует вставлять в код всякий раз, когда она 
может оказаться уместной: 

сһеск ("реЁоге ѕиѕресі"); 


/* ... подозрительный код ... */ 
сһеск ("абер ѕиѕресі") ; 


После исправления ошибки не стоит просто выбрасывать функцию сһеск из ис- 
ходного кода. Оставьте ее в тексте, закомментировав или поместив в условно компи- 
лируемый блок, чтобы при’ появлении следующей трудной ошибки можно было лег- 
ко восстановить вызовы функции. 

Для более тяжелых случаев функцию сһеск можно переделать так, чтобы она вы- 
полняла сложные проверки и вывод структур данных. Этот подход можно обобщить, 
построив систему функций для текущих проверок структур данных и другой рабочей 
информации по ходу выполнения программы. Если в программе используются очень 
сложные структуры данных, то такие проверочные функции неплохо написать зара- 
нее — до того, как случится катастрофа. Их следует систематически спроектировать и 
реализовать вместе с программой, а затем по необходимости активизировать. Пользуй- 
тесь ими не только при отладке; пусть они присутствуют в программе на всех этапах ее 
разработки. Если это не сильно отражается на быстродействии, то полезно даже оста- 
вить их всегда активными. Большие программы наподобие систем телефонной комму- 
тации нередко содержат “ревизионные” подсистемы довольно значительного объема, 
задача которых состоит в контроле состояния информации и оборудования, а также в 
обнаружении и исправлении возникающих ошибок. 


Записывайте файл протокола. Одним из надежных методов отладки является 
протоколирование выполнения программы, т.е. запись потока служебной информа- 
ции в файл в каком-либо фиксированном формате. Если случается авария, в таком 
протоколе можно найти отчет о том, что произошло непосредственно перед аварий- 
ным завершением. \\№!еБ-серверы и другие подобные сетевые программы ведут 
обширные протоколы сетевых транзакций, отслеживая все операции как своих кли- 
ентов, так и самих себя. Вот выдержка из протокола одной из локальных систем: 

[5ип Рес 27 16:19:24 1998] 
НТТРа: ассезз бо /иѕг/1оса1 /һіра/соі-ріп/беѕі . ҺЕт1 
Га11еа Ғог т1.сѕ.ре11-1арѕ.сот 


геаѕоп: с11епЕ депіеа Бу ѕегуег (ССІ поп-ехесибар1е) 
Ғгот ҺЕбр: //т2.сѕ.ре11-1арѕ.сот/сді-ріп/беѕё.р1 
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Не забывайте очищать буферы ввода-вывода, чтобы в протокол попадала самая 
последняя информация. Функции вывода наподобие ргіпе# обычно буферизуют 
выводимые данные, чтобы сделать вывод эффективнее; при аварийном завершении 
программы буферизованные данные могут пропасть. В языке С вызов функции 
ЕЁЕ1азр гарантирует очистку буферов и запись данных перед завершением про- 
граммы; в С++ и Јауа имеются аналогичные функции Ё1азН для потоков вывода. 
Или же, если вы можете позволить себе некоторое уменьшение быстродействия, 
проблему буферизации можно решить, отказавшись от нее при записи протоколов. 
Буферизация управляется стандартными функциями зеераЕ и ѕебуриї; оператор 
зеераЕ (Ёр, МЛ) отключает буферизацию потока Ёр. Обычно по умолчанию 
потоки ошибок (зЕдегг, сегг, бузЕет.егг) не буферизуются. 


Стройте графики. Часто графики и схемы приносят больше пользы при отлад- 
ке, чем текстовые данные. Разного рода графические схемы особенно полезны при 
анализе структур данных (см. главу 2), не говоря уже о программах с графическим 
интерфейсом. Но и в других программах этот подход может пригодиться. Точечные 
диаграммы гораздо лучше показывают отклонения данных от нормы, чем столбцы 
цифр. Элементарная гистограмма данных позволяет обнаружить ненормальные от- 
клонения в сводках экзаменационных оценок, наборах псевдослучайных чисел, раз- 
мерах ячеек в хэш-таблицах и т.п. 

Если вам непонятно, что происходит в вашей программе, попробуйте снабдить 
структуры данных статистикой и вычертить ее графики. Ниже приведены графики 
для программы тагКкоу из главы З (версия на языке С). На них по оси х отложена 
длина цепочек, а по оси у — количество элементов в цепочках данной длины. Здесь 
применяются наши стандартные входные данные в виде текста Псалтыри (42 685 
слов, 22 482 префикса). Первые два графика соответствуют двум благоприятным 
значениям хэш-множителей, 31 и 37, а третий — неблагоприятному множителю 128. 
В первых двух случаях ни одна цепочка не имеет длину больше 15-16 элементов, 
причем большинство элементов организованы в цепочки длиной 5-6 элементов. 
В третьем случае распределение гораздо шире, самая длинная цепочка включает 187 
элементов, и целые тысячи элементов содержатся в цепочках длиннее 20. 


5000 
4000 
3000 
2000 


0 10 20 30 0 10 20 30 


Множитель 31 Множитель 37 Множитель 128 
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Пользуйтесь дополнительными программными средствами. Постарайтесь 
максимально эффективно воспользоваться программными средствами, имеющими- 
ся в той среде, где производится отладка. Например, существует программа Я1ЕЕ, 
способная сравнить выходные данные успешного и аварийного сеансов отладки и 
тем самым дать возможность сконцентрироваться на отличиях между ними. Если 
выходные данные слишком объемисты, воспользуйтесь программой агер для поис- 
ка нужных элементов или текстовым редактором для подробного изучения этих 
данных. Не поддавайтесь искушению вывести выходные данные на печать: компью- 
теры способны отфильтровать большой объем данных лучше, чем это сделает чело- 
век. Используйте сценарии на командных языках и другие подобные средства для 
автоматизации обработки данных, полученных в ходе сеансов отладки. 

Для проверки гипотез или своего понимания работы тех или иных языковых 
средств бывает полезно написать тривиальную программу. Например, допускается 
ли освобождать нулевой указатель? Для ответа на этот вопрос скомпилируйте и 
выполните следующую программу: 


106 таіп (уоіа) 


Ғгее (МТЦ); 
геёоцгп 0; 


} 


Программы контроля изменений в исходном коде, такие как КС$, помогают вес- 
ти учет версий кода. С их помощью можно выяснить, какие изменения вносились в 
программу, и вернуться к одной из предыдущих версий, тем самым восстановив зна- 
комое состояние. Кроме индикации недавних изменений, эти системы выполняют и 
другую важную функцию: они помогают выявить фрагменты кода, давно и часто 
подвергающиеся исправлениям. Именно в таких фрагментах чаще всего скрываются 
ошибки. 


Записывайте все, что вы делаете. Если поиск ошибки продолжается бесконеч- 
но долго, можно легко потерять счет опробованным методам и сделанным выводам. 
Если же записывать проделанные тесты и полученные результаты, то вероятность 
пропустить что-то или ошибочно решить, что какой-то способ вы уже пробовали, 
резко снижается. Ведение записей помогает лучше запомнить суть проблемы на тот 
случай, если она или ей подобная возникнет где-нибудь в следующий раз; сделанные 
записи также помогут объяснить суть проблемы кому-то другому. 


5.4. Тяжелые случаи 


Что делать, если все приведенные выше советы оказались бесполезными? Навер- 
ное, пора взять хороший отладчик и выполнить программу шаг за шагом. Если ваше 
представление о работе программы не соответствует действительности, т.е. вы про- 
сто смотрите не в то место или не видите проблему, глядя на нее в упор, то отладчик 
заставит вас думать по-другому. Ошибки, связанные с неправильным представлени- 
ем о программе, относятся к самым сложным; применение средств автоматизации в 
этом случае просто необходимо. 
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Иногда ошибочное представление имеет простой характер: незнание приоритета 
операций, неправильная конструкция оператора, отступы, не соответствующие 
структуре кода, конфликт области действия, при котором локальное имя превалиру- 
ет над глобальным или глобальное вмешивается в локальную область видимости 
переменных. Например, программисты часто забывают, что знаки операций & и | 
имеют более низкий приоритет, чем == и ! =, и пишут так: 


? ЇЕ (х&т == 0) 
? 


Выражение в скобках всегда ложно, поэтому блок никогда не выполняется, а про- 
граммист этого не осознает. Иногда из-за простой опечатки одинарный знак равен- 
ства (=) превращается в двойной или наоборот: 


? мһі1е ((с == деісһаг()) != ЕОЕ) 
? Еее Аи.) 
Э ргеак; 


Бывает, что из-за крохотной опечатки за бортом остается часть важных операций: 


? Ғог (і = 0; 1 < п; 1++); 
? а[1++] = 0; 


Множество ошибок появилось на свет из-за поспешного набора текста: 


змієсһ (с) { 

саѕе '<': 
поаӢе = 1Е55; 
ргеак; 

саѕе '>!: 
поае = СВЕАТЕК; 
ргеак; 

деҒџца1: 
тоае = ЕОЧАЦ; 
ргеак; 


0 0 0 0 0 000 0 0 0 


} 


Иногда ошибка возникает из-за передачи аргументов в неправильном порядке, 
а контроль соответствия типов ничем помочь не может: 


? тетѕеѓ (р, п, 0); /* поместить п нулей в р */ 


Следовало бы записать это так: 


? тетѕеѓ (р, 0, п); /* поместить п нулей в р */ 


Нередко нежелательные изменения происходят за вашей спиной: модифици- 
руется глобальная переменная или ресурс общего пользования, а вы даже не знаете, 
какие именно модули к ним обращаются и с какими целями. 

Бывает, что алгоритм или структура данных имеет внутренний дефект, а вы его 
не видите. Подготавливая материал по связанным спискам, мы написали пакет 
функций для работы со списками: создание новых элементов, добавление их в 
голову или хвост списка и т.д. (см. главу 2). Разумеется, мы написали и тестовую 
программу для проверки правильности этих функций. Первые несколько тестов 
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прошли успешно, а затем произошел крах. Тестовая программа была, в сущности, 
совсем простой: 


мһі1е (зсапЁ("%5 %а", пате, &уа1ае) != ЕОЕ) { 
р = пем1еещ(паме, уа14е); 
11561 = аааЕгопе (11501, р); 

11362 = аааепа (11362, р); 

Ғог (р = 11561; р != МЈ; р = р->пехі) 
ргіпёЁ ("%5 %0\п", р->пате, р->уа1ае) 


ооо оноо 0 


Найти ошибку оказалось удивительно нелегким делом. Мы совершенно не осоз- 
навали, что в первом цикле один и тот же узел помещался в оба списка таким обра- 
зом, что к моменту начала вывода указатели были безнадежно перепутаны. 

Такие ошибки найти особенно трудно, потому что мозг отказывается заставить 
посмотреть на них в упор и пытается обойти. Здесь большую помощь оказывает от- 
ладчик, поскольку он заставляет мышление повернуть на правильный курс и следо- 
вать за фактическим ходом программы, а не за собственными домыслами. Часто 
проблема бывает связана со структурой всей программы, и для обнаружения ошибки 
приходится начинать с анализа исходных допущений. 

Кстати, заметьте, что в примере со списками ошибка скрывалась в коде тестовой 
программы и поэтому ее было особенно трудно найти. Очень легко увлечься поис- 
ком ошибок там, где их нет, просто потому, что код для тестирования написан 
неправильно, или тестируется не та версия программы, или перед тестированием 
не выполняется перекомпиляция и обновление исходных данных. 

Если вы потратили много труда и не нашли ошибку, сделайте перерыв. Отвлеки- 
тесь от задачи, займитесь чем-то другим. Поговорите с товарищем, попросите его о 
помощи. После этого ответ может прийти сам собой как гром с ясного неба, но даже 
если нет, по крайней мере во время следующего сеанса отладки вы уже не застрянете 
в той же колее. 

В отдельных редких случаях проблема бывает действительно связана с компиля- 
тором, библиотеками, операционной системой или даже с аппаратными компонен- 
тами компьютера, особенно если перед самым появлением ошибки в рабочей среде 
были сделаны какие-то изменения. Никогда не следует начинать поиск ошибки с 
обвинения системных средств, но если все другие подходы уже исчерпаны, остается 
сделать только это. Однажды нам пришлось переносить большую программу форма- 
тирования текста из ее родной среды Ошх на ІВМ РС. Компиляция программы 
прошла успешно, а вот при выполнении начали происходить очень странные вещи: 
пропадал примерно каждый второй символ из ее входных данных. Первая мысль, 
пришедшая нам в голову, была такова, что виноваты 16-разрядные целые числа, ис- 
пользуемые вместо первоначальных 32-разрядных, или еще какая-нибудь проблема 
порядка байтов в переменных. Но путем вывода на экран символов, считываемых 
основным циклом программы, нам все-таки удалось обнаружить ошибку в стандарт- 
ном заголовочном файле скуре .В, входящем в состав компилятора. В нем функция 
іѕргіпё определялась в виде функционального макроса: 


2 #аеҒіпе іѕргіпе (с) ((с) >= 040 && (с) < 0177) 
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Главный рабочий цикл программы был основан на следующем условии: 


2 мһі1е (іѕргіпё (с = деісһаг())) 


Всякий раз, когда поступающий на вход символ представлял собой пробел (его 
числовой восьмеричный код равен 040; это заумный способ записи символа ' ') 
или символ с более старшим кодом, а именно так и происходило в большинстве слу- 
чаев, функция сдеёсһаг вызывалась второй раз, поскольку в макрофункции аргу- 
мент вычислялся два раза. Таким образом, первый из введенных символов пропадал 
навсегда. Да, код программы был написан не так чисто, как следовало бы, — условие 
цикла содержало слишком много операций и допущений. Но заголовочный файл в 
данном случае содержал совершенно непростительную ошибку! 

Время от времени можно встретить примеры аналогичных проблем; например, 
следующий макрос также определен в одном из заголовочных файлов другого ком- 
пилятора: 


? #аеЕ1пе _ іѕсѕут(с) (іѕа1пит(с) || ((с) == '_')) 


Существенной причиной проблемного поведения многих программ является 
“утечка” памяти — невозвращение ресурсов памяти, которые больше не используют- 
ся. Также опасно не закрывать ненужные файлы, потому что со временем таблица 
открытых файлов переполняется, и программа больше не может открыть ни одного. 
Аварийное завершение программы с подобной утечкой выглядит особенно загадоч- 
но, потому что причиной его является недостаток некоторого ресурса, который 
не всегда удается воспроизвести. 

Бывает, что и аппаратура компьютера дает сбои. В свое время в архитектуре про- 
цессора Репііит 1994 года выпуска была допущена ошибка в операциях с плаваю- 
щей точкой; из-за этого многие вычисления давали неверные ответы. Эта ошибка 
широко обсуждалась и стоила больших денег, но как только ее удалось обнаружить, 
она, разумеется, стала легко воспроизводимой. Одна из самых странных ошибок, 
которую нам удавалось наблюдать, происходила давным-давно в программе- 
калькуляторе на двухпроцессорной машине. Иногда вычисление выражения 1/2 
давало в итоге результат 0.5, а иногда — нечто того же порядка, но совершенно 
неправильное, наподобие 0. 7432. При этом не было видно никакой закономерности 
в том, когда же программа дает правильный ответ, а когда — неправильный. В конце 
концов поиск ошибки привел нас к неисправному модулю работы с вещественными 
числами одного из процессоров. Поскольку программа-калькулятор выполнялась то 
одним, то другим процессором, ответы могли быть как правильными, так и бессмыс- 
ленными без всякой закономерности. 

Много лет назад мы работали на ЭВМ, внутреннюю температуру которой было 
легко измерить по количеству младших битов, вычисляемых неправильно при опе- 
рациях над числами с плавающей точкой. Дело в том, что одна из микросхем не- 
плотно сидела в своем гнезде; когда машина прогревалась, микросхема выходила из 
разъема чуть дальше и биты данных отсоединялись от соответствующих контактов. 
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5.5. Невоспроизводимые ошибки 


Труднее всего работать с теми ошибками, которые “не стоят на месте”; как прави- 
ло, при этом не удается свалить вину на сбои аппаратуры. Впрочем, сам факт неде- 
терминированного поведения ошибки уже несет в себе наводящую информацию. 
Он означает, что ошибка, скорее всего, не имеет отношения к алгоритму; ее источник 
кроется в работе с теми данными, которые меняются всякий раз при очередном 
запуске программы. 

Проверьте, все ли переменные инициализированы; ошибка может возникать оттого, 
что из неинициализированной ячейки памяти выбирается случайное значение, остав- 
шееся там от предыдущих задач. Наиболее вероятные виновники таких ситуаций в Си 
С++ — это локальные переменные внутри функций и буферы памяти, выделенные 
функциями распределения памяти. Поэтому помещайте во все переменные известные 
начальные значения. Если в программе фигурирует инициализатор счетчика случай- 
ных чисел, который обычно формируется на основе текущего времени, принудительно 
сделайте его равным фиксированной константе — например, нулю. 

Если ошибка изменяет свой характер или вообще исчезает при добавлении отла- 
дочного кода, то это, скорее всего, ошибка распределения памяти. В каком-то месте 
программы выполняется запись за пределами разрешенной области памяти, а добав- 
ление отладочных операторов изменяет структуру выделяемой памяти в достаточ- 
ной степени, чтобы изменились и проявления ошибки. Большинство функций выво- 
да, от ргіпё# до функций диалоговых окон, тоже участвуют в распределении памя- 
ти, еще больше мутя воду. 

Если в месте аварийного завершения нет ничего похожего на ошибку, то пробле- 
ма, скорее всего, связана с затиранием памяти: в определенный момент какое-то зна- 
чение по ошибке помещается в ячейку памяти, которая будет использоваться гораз- 
до позже. Иногда проблему создает “беспризорный” указатель на локальную пере- 
менную, который возвращается из функции при том, что переменная уничтожается, 
а потом по нему выполняется обращение. Вообще, возвращение адреса локальной 
переменной — верный путь к будущей катастрофе: 


сһаг *тза(1пе п, сһаг *8) 
сһаг БаЕ [100]; 


зре1пЕЕ (риЁ, "екгог %А: %5\п", п, 5); 


? 
? 
2 
9 
? 
9 геёогп ри; 
5 


} 


К тому времени, как произойдет обращение по указателю, возвращаемому из 
функции шза, он больше не будет указывать на место в памяти, содержащее какую- 
либо осмысленную информацию. Необходимо создавать буфер памяти с помощью 
функции ма11ос, использовать массив с модификатором зе аЕ1с или же обеспечи- 
вать корректное распределение памяти в вызывающем модуле. 

Аналогичные симптомы проявляются при попытке воспользоваться динамически 
выделенным буфером после того, как его освободили. Эта ситуация уже упомина- 
лась в главе 2 в связи с функцией Егееа11. Вот этот код ошибочен: 
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2 Ғог (р = 1іѕєр; р != МОШ; р = р->пехі) 
Ғүгее (р); 


о 


После освобождения памяти обращаться к ней больше не следует, поскольку ее 
содержимое может измениться, и нет никакой гарантии, что р->пехЕ по-прежнему 
будет указывать на нужный адрес памяти. 

В некоторых реализациях функций та11ос и Ёгее при двойном освобождении 
одного и того же буфера памяти повреждаются внутренние структуры данных. Од- 
нако проблема проявляется значительно позднее, когда программа наконец натал- 
кивается на мешанину, которая возникла в результате такой операции. В некоторых 
функциях распределения памяти имеются отладочные режимы, после активизации 
которых корректность распределения проверяется при каждом вызове. Активизи- 
руйте такой режим, если у вас появилась ошибка недетерминистического характера. 
Если это не поможет, можно написать свою собственную функцию распределения, 
выполняющую часть необходимых проверок или ведущую протокол всех вызовов 
для последующего анализа. Такую функцию написать довольно легко, если нет не- 
обходимости заботиться о быстродействии. В запутанных ситуациях это помогает. 
Имеются превосходные коммерческие продукты, обеспечивающие управление па- 
мятью, проверку утечек и т.п.; если у вас нет к ним доступа, то хорошая альтернати- 
ва — это как раз написать свои собственные функции та11оси Ёгее. 

Если программа работает у одного пользователя, но дает сбои у другого, то вино- 
вата может быть внешняя среда, в которой она выполняется. На работу программы 
влияют файлы, считываемые программой, допуски к файлам, системные перемен- 
ные, заданные в системе стандартные пути, установки по умолчанию и т.п. Для та- 
ких ситуаций трудно посоветовать что-либо определенное. Обычно требуется разо- 
браться в том, от каких параметров среды зависит программа, и скорректировать их 
соответственно. 


Упражнение 5.1. Напишите версии функций та11ос и Егее, которые можно 
было бы использовать при отладке программ с ошибками управления памятью. 
Один из подходов к реализации таких функций состоит в том, чтобы проверять все 
рабочее пространство при каждом вызове та11ос или Ёгее, а другой — протоко- 
лировать всю информацию, которая может пригодиться для анализа с помощью 
других программ. В любом из случаев вставьте маркеры начала и конца в каждый 
выделяемый блок памяти для контроля переполнения с каждой из сторон. 


5.6. Вспомогательные средства 


Отладчик — это не единственное программное средство для поиска ошибок. Суще- 
ствует целый ряд программ, с помощью которых можно обработать объемистые вы- 
ходные данные и найти в них важные фрагменты текста или аномальные явления, а 
также переупорядочить данные для более легкого их восприятия. Многие из таких 
программ входят в стандартные инструментарии разработчика, а некоторые написаны 
специально для поиска конкретных ошибок или анализа конкретной программы. 

В этом разделе будет рассмотрена простая программа под названием зЕх1паз, 
особенно полезная при чтении файлов, состоящих в основном из неотображаемых 
или непечатаемых символов, — исполняемых файлов и неразборчивых двоичных 


Раздел 5.6 Вспомогательные средства 157 


потоков, используемых текстовыми редакторами для хранения форматированных 
текстов. В таких файлах часто содержится полезная информация — например, текст 
документа, сообщения об ошибках, недокументированные ключи или возможности, 
имена файлов и каталогов, имена вызываемых программой функций. 

Мы обнаружили, что программа 5Ех1паз удобна для поиска текста и в других ви- 
дах двоичных файлов. Файлы графических изображений часто содержат текстовые 
А$СП-строки, идентифицирующие те программы, с помощью которых данные изо- 
бражения создавались. Сжатые файлы и архивы (например, в формате 2ір) могут со- 
держать имена файлов. Программа ѕсгіпоѕ может обнаружить и эту информацию. 

В системах семейства Опіх реализация программы зЕх1п95 уже есть, хотя и 
несколько отличается от приведенной в этом разделе. Она распознает исполняемые 
файлы (программы) и анализирует только их текстовые сегменты и разделы данных, 
игнорируя таблицы символов. Чтобы заставить ее просматривать весь файл, исполь- 
зуется ключ -а. 

Фактически программа =Ех1паз извлекает АЗСП-текст из двоичного файла для 
последующего чтения или обработки другими программами. Например, если сооб- 
щение об ошибке не несет никакой информации, можно не понять даже то, какая 
программа его выдала, не говоря уже о сути ошибки. В этом случае программу мож- 
но обнаружить, организовав поиск по вероятным каталогам с помощью команды 
такого типа: 


о, 


5 зігіпаѕ *.ехе *.111 | гер ! непонятное сообщение! 


Функция ѕёгіпдѕ считывает файл и выводит все последовательности из не 
менее чем МТМЬЕМ = 6 отображаемых символов. 


/* ѕЕгіпдѕ: извлекает отображаемые символы из потока */ 
уоіа зЕг1паз (сһаг *пате, ЕТЬЕ *Ғіп) 
{ 

ТАЕ е1 

сһаг ЫЬи# [ВОЕЅІ2]; 


до { /* один раз для каждой строки */ 
Ғог (і = 0; (с = дебс(Ғіп)) != ЕОР; ) { 
1Е (!іѕргіпё (с)) 
ргеак; 
БаЕ [1++] = с; 
1Е (1 >= ВОЕЅІ2) 
Ьгеак; 


} 


1Е (1 >= МТМЬЕМ) /* вывести, если длина достаточна */ 
ре1пЕЕ("%3:%.*з\п", пате, і, БаЕЁ); 
} мые (с != ЕОР); 


} 


Спецификация вывода % . *5 в строке формата функции ру1пЕЕ указывает взять 
длину строки из следующего аргумента (і), поскольку данная строка (риё) 
не заканчивается нулевым символом. 

В цикле ао-мћі1е каждая имеющаяся в файле строка последовательно обнару- 
живается и выводится на экран; его работа заканчивается, когда встречается конец 
файла (ЕОР). Проверка конца файла в самом конце цикла позволяет циклу с вызо- 
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вом дес и основному циклу функции завершиться по одному и тому же условию и 
при этом обойтись одним вызовом ре1пЕЕ для работы с концом строки, концом 
файла и слишком длинной строкой. 

Если бы использовался стандартный внешний цикл с проверкой в начале или 
один цикл с вызовом дес, но более сложным телом, то потребовалось бы дублиро- 
вать вызов рг1 пе Е. Эта функция именно так и начинала свою жизнь, но в ней была 
ошибка, причем именно в операторе вызова ргіпе ғ. Мы исправили ее в одном мес- 
те, но забыли исправить еще в двух других. (Не забывайте задавать себе вопрос: 
“Несделал ли я одну и ту же ошибку несколько раз?”) В тот момент стало ясно, что 
лучше переписать программу и избежать дублирования кода; в результате возник 
цикл до-мћі1е. 

Главная функция программы вызывает функцию ѕёгіпоѕ для каждого из 
файлов, переданных в программу в качестве аргументов: 

/* зЕхг1па8 таіп: ищет отображаемые строки в файлах */ 
106 таіп (іп агас, сһаг *агүду[]) 


{ 


іпЕ і; 
ЕТЬЕ *Ғіп; 
ѕесргодпате ("ѕігіпаѕ"); 
1Е (аүдс == 1) 
ергіпб# ("цѕаде: ѕігіпдѕ Ғі1епатеѕ"); 
е1зе { 
Ғор (і = 1; і < арас; 1++) { 
1Е ((Ғіп = Ёореп (агау [1], "гЬ")) == МЈ) 
мергіпі Ё ("сап'Е ореп %5:", агду[і]); 
е1зе { 


зігіпаѕ (агау [1], Ғіп); 
Ес1озе (Ғіп); 


} 


геіогп 0; 


} 


Должно быть, вы удивлены, что программа ѕёгіпазѕ не считывает данные из 
стандартного потока ввода, если ей не заданы файлы-аргументы. В начале своего 
существования она это делала. Чтобы объяснить, почему сейчас это не так, необхо- 
димо рассказать историю ее отладки. 

Самый очевидный тест программы зЕх1паз состоял в том, чтобы дать ей для об- 
работки ее же исполняемый файл. В системе Чтих все работало нормально; 
в Міпдом 95 была задана следующая команда: 


С:\> ѕігіпаѕ <ѕігіпаѕ.ехе 


Результат состоял ровно из пяти строк: 


!Тһіѕ ргодгат саппої ре гоп іп роѕ поде. 
\‘.гааѓа 
@.Часа 
.1Часа 
.хе1ос 
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Первая строка напоминает сообщение об ошибке, и мы потратили зря некоторое 
время, прежде чем поняли, что это текстовая строка из самой программы в скомпи- 
лированном виде. Не так уж редко случается, что сеанс отладки идет вкривь и вкось 
из-за неправильного понимания источника того или иного сообщения. 

Итак, программа вроде бы выводит какие-то данные, но их явно должно быть 
больше. Где же они? Следующим вечером перед нами наконец забрезжил свет. 
(“Где-то я это уже видел!”) Это была проблема переносимости, рассматриваемая бо- 
лее подробно в главе 8. Первоначально мы написали программу так, чтобы она счи- 
тывала данные только из стандартного потока ввода с использованием функции 
аеёсһаг. Однако в системе \/т4о\з функция чеёсһаг возвращает ЕОЕ в том слу- 
чае, если встречает определенный байт (0х1А или <СИ1-7>) во входном потоке. 
Это и было причиной преждевременного окончания работы программы. 

Все это абсолютно корректно с точки зрения языка и системы, но явно не то, на 
что мы рассчитывали с нашим опытом работы в Отих. Мы собирались решить про- 
блему, открыв файл для чтения в двоичном режиме (со спецификацией "хь“). 
Но поток зЕ91п всегда открыт, и не существует стандартного способа изменить 
режим ввода из него. (Можно было бы воспользоваться функциями наподобие 
Едореп или ѕестоде, но они не принадлежат к АМ$[-стандарту С.) В конце концов 
мы встали перед необходимостью неприятного выбора одной из нескольких 
альтернатив: заставить пользователя всегда задавать имя файла (что корректно 
работает в №іпіоҹѕ, но непривычно в Отх); молча выдавать неправильные ответы, 
если пользователь \п4о\з пытается читать данные из стандартного потока ввода; 
использовать условную компиляцию для адаптации программы к разным средам, 
ухудшив тем самым переносимость программы. Мы выбрали первый вариант, чтобы 
одна и та же программа работала совершенно одинаково в разных средах. 


Упражнение 5.2. Программа ѕсгіпаоѕ выводит строки, состоящие из МТМЬЕМ 
или большего количества отображаемых символов. Иногда это дает больше данных, 
чем хотелось бы. Усовершенствуйте программу так, чтобы в ней использовался не- 
обязательный аргумент, задающий минимальную длину строки. 


Упражнение 5.3. Напишите программу уіѕ, копирующую входной поток в вы- 
ходной с заменой всех неотображаемых байтов (управляющих символов и т.п.), 
а также символов за пределами набора АЗСП, последовательностями вида \ХВВ, где 
ҺҺ — шестнадцатеричное представление соответствующего байта. В противополож- 
ность программе ѕёгіпаѕ, программа уізѕ наиболее полезна для обработки потоков 
с совсем небольшим количеством неотображаемых символов. 


Упражнение 5.4. Какой результат выдаст программа уі 5, если подать ей на вход 
поток вида \ХОА? Как сделать результаты ее работы однозначными и недвусмыс- 
ленными? 


Упражнение 5.5. Усовершенствуйте программу уізѕ так, чтобы она обрабатывала 
последовательности файлов, сворачивала длинные строки по любой заданной пози- 
ции, а также вообще удаляла неотображаемые символы. Какие еще возможности 
можно добавить в эту программу, исходя из ее назначения? 
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5.7. Ошибки, сделанные другими 


Будем реалистами: большинство программистов не прельщает перспектива раз- 
работки совершенно новой системы с нуля. Вместо этого программисты в основном 
заняты переносом, доработкой, исправлением и (неизбежно) отладкой кода, напи- 
санного кем-то другим. 

При отладке чужого кода сохраняют свою силу все принципы и рекомендации, 
которые мы привели в связи с отладкой своего собственного. Правда, перед отлад- 
кой такого кода вначале необходимо составить некоторое представление о том, как 
организована программа, как мыслили и писали ее авторы. Такая работа в отноше- 
нии одного очень большого программного проекта была названа “разведкой”, и это 
небезосновательная метафора. Задача, стоящая перед программистами, заключается 
в том, чтобы разведать, что и как происходит в системе, которую они впервые видят, 
так сказать, изнутри. 

В этой работе очень существенную помощь могут оказать программные средства 
автоматизации. Все вхождения тех или иных имен в тексте можно найти с помощью 
программ текстуального поиска типа агер. Программы анализа перекрестных ссылок 
дают некоторое представление о структуре программы. Полезно иметь перед глазами 
схему графа функциональных вызовов в программе, если только она не слишком 
велика. Последовательность событий в программе восстанавливается путем пошагово- 
го выполнения в среде отладчика. История версий и изменений программы дает поня- 
тие об эволюции программы во времени. Частые изменения отдельных частей про- 
граммы сигнализируют о том, что авторы плохо понимали работу данных фрагментов 
или непрерывно приспосабливали их к меняющимся требованиям. В обоих случаях 
такие части программы особенно подвержены ошибкам. 

Иногда приходится искать ошибки в программах, разработка которых не в вашей 
власти, и даже их исходного кода у вас нет. В этом случае задача заключается в том, 
чтобы идентифицировать и охарактеризовать ошибку достаточно подробно, соста- 
вив полный отчет о ее проявлениях, и в то же время найти способ избежать этой 
ошибки при пользовании программой. 

Если вам кажется, что вы нашли ошибку в чьей-то программе, постарайтесь абсо- 
лютно точно убедиться, что ошибка действительно существует, иначе вы зря потра- 
тите время автора программы и подорвете доверие к себе. 

Если на первый взгляд обнаруживается ошибка в компиляторе, необходимо сна- 
чала убедиться, что дело не в коде, а действительно в компиляторе. Например, 
в языках Си С++ не определено, должна ли операция поразрядного сдвига вправо 
заполнять очищенные биты нулями (логический сдвиг) или значением знакового 
бита (арифметический сдвиг). Поэтому новички часто обвиняют компилятор, если 
приведенная ниже конструкция дает неожиданный ответ. 

2 і = -1; 
? ргіпёЁ ("%а\п"®, і >> 1); 


На самом же деле это проблема совместимости и переносимости, потому что 
такая операция выполняется по-разному на разных платформах. Поэтому следует 
протестировать код в разных средах, чтобы понять, что же в действительности про- 
исходит. Стоит также обратиться к описаниям и стандартам языка. 
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Убедитесь, что вы имеете дело с новой ошибкой. Имеется ли у вас новейшая вер- 
сия программы? Прилагается ли к ней список исправленных ошибок? Большинство 
публично распространяемых программ за срок своего существования выпускается 
во множестве версий; если вы нашли ошибку в версии 4.0Ъ1, она уже вполне может 
быть исправлена (или заменена на другую) в версии 4.0452. Обычно программисты 
имеют привычку исправлять ошибки только в самых последних, текущих версиях 
своих программ. 

Наконец, поставьте себя на место человека, для которого вы пишете отчет об 
ошибке. По возможности, владелец программы должен получить исчерпывающие 
тестовые данные, полностью характеризующие ошибку. Помощь с вашей стороны не 
покажется слишком эффективной, если ошибку можно будет продемонстрировать 
только на огромном массиве входных данных, или в сложной выполняющей среде, 
или в специальном файловом окружении. Сделайте тестовый набор данных мини- 
мальным и самодостаточным. Включите в отчет всю существенную информацию, 
такую как нужные версии самой программы, компилятора, операционной системы и 
аппаратных компонентов. Например, для ошибочной версии функции іѕргіпе, 
рассмотренной в разделе 5.4, можно предложить следующую тестовую программу: 

/* тестовая программа для функции 1ври1пЕ */ 
106 таіп (уоіа) 


{ 


іп с; 

мһі1е (іѕргіпё (с = дессһаг()) || с != ЕОЕ) 
ргіпёғҒ ("%с", с); 

геигп 0; 


} 


В качестве тестовых данных подойдет любая строка отображаемых СИМВОЛОВ, 
поскольку на выходе все равно будет получена всего половина входного потока: 


% есһо 1234567890 | 1врх1пЕ сезЕ 
24680 


% 


Лучший отчет об ошибке должен содержать тестовые исходные данные в количе- 
стве одной-двух строк; программа должна выполняться с этими данными в про- 
стейшей операционной среде и при этом гарантированно демонстрировать ошибку. 
Желательно, чтобы в совокупности вся эта информация позволяла легко решить 
проблему. Короче говоря, представляйте другим такие отчеты об ошибках, какие вы 
хотели бы получить сами. 


5.8. Резюме 


При правильном отношении к делу отладка может стать даже развлечением 
чем-то вроде решения головоломки. Но как бы ни относился к ней программист как 
к развлечению или как к тяжелой работе, — все равно это искусство, в котором 
приходится упражняться регулярно. Было бы хорошо, если бы ошибки вообще 
не случались; вот для чего мы стараемся писать программы в хорошем стиле с само- 
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го начала. Хорошо написанный код содержит мало ошибок, а те, которые в нем воз- 
никают, легче найти и исправить. 

Как только обнаруживается ошибка, надо сразу же хорошенько задуматься над ее 
симптомами. Как она возникает? Знакомы ли вам ее проявления? Какие изменения 
вносились в программу в последнее время? Что такого особенного в исходных дан- 
ных, которые ее спровоцировали? Для решения проблемы может хватить несколь- 
ких удачно подобранных тестовых примеров и пары операторов контрольного выво- 
да в тексте программы. 

Если симптомы неочевидны, следует задуматься еще сильнее. Хорошо подумав, 
нужно браться за локализацию ошибки, следуя при этом определенной системе. 
Первый шаг — это урезать входные данные до минимума, при котором ошибка все 
еще проявляется. Второй шаг — урезать код аналогичным образом, чтобы оставить в 
нем только аварийно-опасные фрагменты. Вполне можно вставить несколько кон- 
трольных операторов, активизируемых только на определенном этапе выполнения 
программы; это также помогает локализовать проблему. Все это примеры более об- 
щей стратегии — “разделяй и властвуй”, — которая столь же эффективна в програм- 
мировании, как в политике и на войне. 

Прибегайте к вспомогательным средствам. Объясните ваш код кому-то другому 
(хотя бы и плюшевому медведю); это очень эффективно. Получите стековый фрейм 
с помощью отладчика и проанализируйте его. Воспользуйтесь коммерческими про- 
граммами, способными проверять утечки памяти, нарушения границ массивов и 
другие подозрительные конструкции. Если станет ясно, что ваше представление о 
работе кода сильно расходится с действительностью, выполните программу в поша- 
говом режиме. 

Постарайтесь лучше узнать себя и те ошибки, которые вы имеете привычку 
делать. Найдя и устранив ошибку, не пропустите остальные аналогичные недочеты в 
коде. Хорошенько обдумайте случившееся, чтобы по возможности не допустить его 
повторения. 


Дополнительная литература 


Много полезных рекомендаций по отладке кода можно найти в книгах З(еуе 
Мавште, Ипа 5оЁа Соае (М1сгозоЁ Ргеѕѕ, 1993) и Ѕсеуе МсСоппе!|, Сойе Сотріеіе 
(М1сгозоЁ Ргеѕѕ, 1993). 


Тестирование 


В практике вычислений, выполняемых вручную или с помощью настольных 
вычислительных машин, обычно тщательно проверяют процесс расчета, 
и если обнаруживается ошибка, то ее локализуют с помощью обратной 
процедуры, которая начинается с первого места ее проявления. 


Норберт Винер. “Кибернетика” 
(Мотфет Иепег, Сурегпейсз) 


Тестирование и отладку нередко объединяют в одну процедуру, но все же это 
разные операции с разными целями. Если упростить их суть до предела, то можно 
сказать, что отладка — это то, что делается, когда известно, что программа работает 
ошибочно и ее нужно исправить. Тестирование же — это систематические и настой- 
чивые попытки сломить сопротивление нормально работающей программы и заста- 
вить ее сделать ошибку. 

Эдсгер Дейкстра (Е4ѕвег Оцкз&га) как-то сделал знаменитое наблюдение, что тес- 
тирование способно продемонстрировать наличие ошибок, но не их отсутствие. 
Он надеялся добиться такого уровня разработки программ, чтобы по самой своей 
конструкции они могли быть только правильными, не содержали ошибок и не тре- 
бовали бы тестирования. Это прекрасная и достойная цель, но пока, к сожалению, 
недостижимая в программах сколько-нибудь существенного размера. Поэтому в 
этой главе мы сосредоточим внимание на том, как проводить тестирование с целью 
быстрого и эффективного поиска ошибок. 

Хороший задел для успешного тестирования — это обдумывание потенциальных 
проблем по ходу написания кода. Систематическое тестирование, включающее в се- 
бя как самые простые, так и очень сложные, подробные тесты, помогает гарантиро- 
вать правильность программы с самого начала и на всем протяжении ее существова- 
ния. Автоматизация позволяет сократить объем ручной работы и поощряет про- 
граммиста к тестированию. Наконец, существует множество особых приемов, 
которым каждый программист учится на собственном опыте. 

Один из верных способов написания безошибочного кода — это его генерирова- 
ние специальной программой. Если какая-нибудь задача программирования изучена 
и формализована настолько хорошо, что ее реализация является совершеннейшей 
рутиной, то ее желательно механизировать. Общий случай такой механизации — это 
генерирование программы на основе спецификации, написанной на некотором спе- 
циализированном языке. Например, программы на языках высокого уровня транс- 
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лируются в код на языке ассемблера; для задания образцов поиска в тексте исполь- 
зуются регулярные выражения; для определения операций над группами ячеек в 
электронных таблицах используются такие условные обозначения, как 50М (А1:А50) 
и т.д. В таких случаях, если генератор или транслятор работает правильно и специ- 
фикация также составлена правильно, то получившаяся в результате программа 
просто обязана быть правильной. Эта обширная тема будет рассмотрена более под- 
робно в главе 9, а в этой главе мы вкратце поговорим о способах разработки тестов 
на основе компактных спецификаций. 


6.1. Тестирование по мере написания кода 


Чем раньше найдена проблема, тем лучше. Если систематически обдумывать то, 
что вы пишете, прямо по ходу написания, то простейшие свойства программы можно 
проверять непосредственно при ее создании, и в результате программа пройдет пер- 
вую, тривиальную, стадию тестирования еще до компиляции. Некоторые виды оши- 
бок можно таким образом вообще устранить из своей практики. 


Проверяйте граничные условия и предельные случаи. Одним из эффективных 
методов является проверка граничных условий: по мере написания небольших блоков 
кода — например, циклов или условных операторов — проверяйте на месте, разветв- 
ляется ли выполнение по правильному пути и выполняется ли цикл нужное количе- 
ство раз. Этот процесс называется проверкой граничных условий (или предельных 
случаев) по той причине, что контроль правильности выполняется на естественных 
границах кода и данных. К этой же технике относится проверка работы с несущест- 
вующим, пустым или состоящим из одного элемента потоком ввода, с целиком 
заполненным буфером и т.п. Главная идея состоит в том, что ошибки как раз чаще 
всего случаются на подобных границах. Если фрагмент кода может потерпеть крах, 
это скорее всего будет связано с одним из возможных предельных случаев. Соответ- 
ственно, если фрагмент кода нормально работает на границах, он скорее всего будет 
корректно работать и в остальных ситуациях. 

В следующем фрагменте, имитирующем работу функции Едесз, из потока счи- 
тываются символы, пока не встретится символ конца строки или пока не перепол- 
нится буфер: 


? 106 і; 

? сһаг [МАХ]; 

? 

? Ғог (і = 0; (3[1] = деёсһаү()) != '\п' && 1 < МАХ-1; ++1) 
? ; 

? 8[--1] = '\0'; 


Представьте себе, что вы только что написали этот цикл. Прокрутите его мыс- 
ленно, считывая воображаемую строку. Первое граничное условие, которое нужно 
проверить, имеет самый простой вид — это пустая строка. Возьмем текстовую стро- 
ку, не содержащую ничего, кроме символа конца строки '\п'. Легко заметить, что 
цикл закончится на первом же проходе и переменная і останется равной 0. В по- 
следней строке кода эта переменная уменьшится на единицу и станет равной -1, 
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после чего в позицию = [-1], т.е. перед началом символьного буфера, будет записан 
нулевой байт. Проверка предельного случая сразу же обнаружила ошибку. 

Если переписать код с применением стандартной конструкции для заполнения 
массива вводимыми из потока символами, то получится следующее: 


? Рог (і = 0; і < МАХ-1; 1++) 

? 1Е ((5[1] = чеесвак()) == '\п') 
? Ьгеак; 

? 3[1] = '\0'; 


Повторяя проверку, убеждаемся, что пустая строка теперь обрабатывается кор- 
ректно: переменная 1 равна нулю, на первом же символе цикл заканчивает работу, 
ив позицию з[0] помещается символ конца строки '\0'. Проанализировав для 
верности работу цикла со строками длиной 1 или 2 символа, завершаемыми симво- 
лами конца строки, можно убедиться, что в районе этого предельного случая код 
работает правильно. 

Но есть и другие граничные условия, которые необходимо проверить. Если вход- 
ной поток содержит слишком длинную строку или вообще не содержит символов 
конца строки, это проверяется сравнением 1 с верхним предельным значением 
МАХ-1. Но что если входной поток пуст и первый же вызов функции деёсћаг 
возвращает ЕОЕ? Это также необходимо контролировать: 


? Ғог (і = 0; і < МАХ-1; 1++) 

? 1Е ((3[1] = аеёсһаг()) == '\п' || 3[1] == ЕОР) 
? ргеак; 

? 5[1] = '\0'; 


Проверка предельных случаев может выловить множество разных ошибок, но, 
к сожалению, не все. Мы вернемся к этому примеру в главе 8 и покажем, что в нем 
существует еще и проблема переносимости. 

Следующий шаг — это проверить предельный случай на другой границе, когда мас- 
сив практически заполнен, заполнен в точности до единого элемента, а также перепол- 
нен; в частности, надо проверить, что будет, если в момент переполнения из потока как 
раз поступает символ конца строки. Опустим подробности и оставим этот анализ чита- 
телю в качестве упражнения. При обдумывании предельных случаев возникает вопрос, 
что делать, когда буфер заполняется непосредственно перед поступлением символа 
"\2'; этот пробел в спецификации алгоритма необходимо заполнить как можно рань- 
ше, аобнаружить его помогает как раз проверка граничных условий. 

Такие проверки помогают также обнаружить ошибки подсчета объектов, связан- 
ные с занижением или завышением их количества на единицу. По мере накопления 
опыта программист начинает выполнять эти проверки подсознательно, и многие 
тривиальные ошибки устраняются еще до того, как попадут в программу. 


Проверяйте предусловия и постусловия. Еще один способ профилактики оши- 
бок состоит в том, чтобы убедиться, что некоторые ожидаемые или необходимые 
условия выполняются до (предусловия) и после (постусловия) определенного 
фрагмента кода. Распространенный случай предусловий — это проверка того, что 
введенные исходные данные принадлежат к требуемому диапазону. Следующая 
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функция для вычисления среднего арифметического п элементов массива работает 
неправильно, если п меньше или равно нулю: 


аоцр1е ауд (доцр1е а[], 116 п) 


106 і; 
доцр1іе зим; 


зим = 0.0; 

Ғог (і = 0; і < п; і++) 
зим += а[1]; 

геёџгп зам / п; 


0 0 0 0 0 0 0 0 0 0 


} 


Что должна делать функция ауч, если аргумент п равен нулю? Массив без 
элементов — это вполне реальное понятие, а вот его среднее значение — нет. Следует 
ли функции ау позволять системе перехватывать деление на 0? Аварийно завер- 
шаться? Сообщать об ошибке? Возвращать некое условное безобидное значение? 
Что если число п отрицательно (это лишено математического смысла, но вполне 
может случиться)? Как предлагалось в главе 4, предпочтительнее всего возвратить 0 
в качестве среднего значения, если аргумент п меньше или равен нулю: 


геёцгп п <= 0 ? 0.0 : эим/п; 


И все же однозначно правильного ответа на возникшие вопросы мы так и не дали. 
А вот гарантированно неправильный ответ — это вообще игнорировать проблему. 
В одной статье из журнала Ѕсіепіїјіс Атепсап за ноябрь 1998 года рассказывается об 
инциденте, произошедшем на американском военном корабле “Үогкіоуп” — крейсе- 
ре, несущем управляемые ракеты. Один из членов команды непреднамеренно ввел 0 
в ответ на запрос элемента данных. В результате произошло деление на нуль, эта 
ошибка вызвала каскад других ошибок, и в конечном итоге отключилось управление 
двигательной системой корабля. Крейсер безвольно дрейфовал в море в течение не- 


скольких часов только потому, что управляющая программа не проверяла коррект- 
ность входных данных. 


Используйте контрольные условия. В языках С и С++ имеются средства для 
проверки контрольных предусловий и постусловий, объявленные в заголовочном 
файле <аззехке.Н>. Если контрольное условие не выполняется, программа завер- 
шается аварийно, поэтому такие условия приберегают для ситуаций действительно 
неожиданных, в которых причина краха неизвестна, а дальнейшая работа програм- 
мы невозможна. Приведенный выше код можно дополнить проверкой контрольного 
условия перед циклом: 


аѕѕегіё (п > 0); 


Если контрольное условие нарушается, программа завершается аварийно, выда- 
вая стандартное сообщение: 


Аѕѕегібіоп Ёа11еа: п > 0, Е11е аучЕезе.с, Ііпе 7 
Арогі (сгаѕћһ) 


Контрольные условия особенно полезны для проверки правильности работы ин- 
терфейсов, поскольку привлекают внимание к несогласованности между вызываю- 
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щими и вызываемыми модулями, и даже иногда помогают определить, кто из них 
виноват. Если контрольное условие того, что п больше нуля, не выполняется при 
вызове функции, то это однозначно указывает на источник проблемы в вызывающем 
модуле, а не в самой функции ауд. Если интерфейс изменяется, а программист 
забывает внести соответствующие исправления в модуль, обращающийся к этому 
интерфейсу, то контрольное условие может помочь перехватить ошибку до того, как 
она действительно натворит бед. 


Предусматривайте все случаи. Хорошей практикой следует считать добавле- 
ние в программу кода на случай ситуаций, которые “не могут произойти”. Здесь име- 
ется в виду, что некоторые ошибки никак не могут случиться по вине программы, 
однако все же возникают в силу посторонних непредсказуемых обстоятельств. Один 
из примеров — это проверка отрицательной или нулевой длины массива в функции 
ауд. Другой пример: в программе для обработки экзаменационных оценок вроде бы 
нет причин ожидать очень больших или отрицательных чисел во входном потоке, но 
проверять это все равно необходимо: 

1Е (гае < о | 

тевех- =: 

е1ѕе 1Е (дүайе >= 90) 
' 


Іебёег = 'А'!; 
е1зе 


| акаае > 100) /* невозможный случай */ 
5 


Это пример безопасного стиля программирования, при котором программа сама 
защищает себя от неправильно введенных данных или другого некорректного обраще- 
ния. Всегда можно предотвратить или корректно обработать такие ситуации, как нуле- 
вые значения указателей, выход за пределы массивов, деление на нуль ит.п. Если бы в 
управляющей программе на крейсере “Үогкіомп” были предусмотрены подобные 
меры, описанный выше инцидент с делением на нуль мог бы вовсе не произойти. 


Проверяйте коды ошибок, возвращаемые из функций. Одна из защитных мер, 
которыми часто пренебрегают, — это проверка того, не возвратила ли библиотечная 
или системная функция код ошибки вместо кода нормального завершения. Значе- 
ния, возвращаемые функциями ввода наподобие Ғгеаа и ЁЕзсапЕ, следует прове- 
рять обязательно, как и результаты операций открытия файлов с помощью функции 
Ғореп. Если открытие файла или чтение из него невозможно, то дальнейшие вычис- 
лительные операции не имеют смысла и не могут продолжаться корректно. 

Проверка кода, возвращаемого функциями вывода наподобие Ерх1пЕЕ или 
Емт1 ее, позволяет обнаружить ошибку, возникающую из-за попытки записи на диск, 
где не хватает свободного пространства. Иногда бывает достаточно проверить значе- 
ние, возвращаемое функцией Ес1озе, которое равно ЕОЕ, если в процессе выполнения 
какой-либо операции с файлом случается ошибка, и 0 — в противном случае. 


Ер = Ёореп (оціҒі1е, "м"); 


мһі1е (...) /* запись в оціѓЁі1е */ 
Еру1пЕЕ(Ёр, ...); 
1Е (Ес1озе(Ёр) == ЕОР) { /* есть ошибки? */ 


/* обработка ошибки вывода */ 
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Ошибки вывода могут иметь самые серьезные последствия. Если, например, за- 
писываемый файл является новой версией файла, содержащего ценную (а то и бес- 
ценную) информацию, то проверка ошибок позволит сохранить старый файл, если 
вдруг новый не записался корректно. 

Трудозатраты при тестировании прямо по ходу написания программы мини- 
мальны и окупаются сторицей. Если сразу в ходе разработки думать о тестировании, 
то и код получается лучшего качества, потому что именно тогда-то вы и знаете луч- 
ше всего, что и как должна делать программа. Если же вместо этого ждать, пока не 
проявятся ошибки, то к тому времени можно забыть многие подробности работы 
кода. Придется вспоминать все заново, а это требует времени и усилий. В результате 
в условиях цейтнота не удастся выполнить настолько тщательную и всестороннюю 
коррекцию программы, насколько следовало бы, потому что ее знание и понимание 
непременно ухудшится за время, прошедшее с момента ее написания. 


Упражнение 6.1. Выполните проверки граничных условий, предельных случаев в 
приведенных ниже программах, а затем внесите исправления в соответствии с прин- 
ципами стилистики, изложенными в главе 1. 


а) Вычисление факториала: 


гебигп Гас; 


? ты Ғасіогіа1 (іпё п) 
Бу 

? іп Гас; 

? Ғас = 1; 

? мһі1е (п--); 

? Ғас *= п; 

? 

? 


} 


б) Вывод символов текстового буфера по одному в каждой строке: 


і = 0; 

ао 
риєсћһаг ($ [1++]); 
риёсћах ('\п'); 

} мые (5[1] != '\0'); 


ооо 


в) Копирование строки текста из одного буфера в другой: 


9 уоіа зЕхсру(спахг *деѕі, сһаг *ѕүс) 

2 

? тие. 9; 

2 

? Бог (і = 0; ѕүс [1] != '\0'; і++) 
? деѕі [і] = экс [і]; 

2. 


} 


г) Еще одна процедура копирования, на этот раз п символов из строки ѕв є: 


? уоіа зЕгспру (сһаг *6, сһаг *5, іпі п) 
? 

? мһі1е (п > 0 && *в != '\0') { 

? хр = *5; 

? 


С++; 
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ооо 


д) Сравнение чисел: 
сер 

ргіпсё ("%а іѕ дгеабег Пап %а.\п", і, ј); 
е1ѕе 

ргіпеѓ ("ға 15 ѕэта11ег ёһап %а.\п", 1, ј); 


хо 


е) Классификация символов: 


ЇЁ (с >= 'А' && с <= '2') { 
Ее Ти) 
соці << "Ғігѕі Һа1# оЁ а1рһареб"; 
е1ѕе 
соці << "ѕесопа һаїЁ оЁ а1рһареб"; 


0 0 0 р 0 0 


} 


Упражнение 6.2. Эта книга писалась в конце 1998 года, когда перед миром вста- 
ла, пожалуй, самая грандиозная проблема “проверки предельного случая” — пробле- 
ма 2000 года. 


а) Какие даты вы бы использовали для тестирования работы системы в 2000 году? 
Предположим, что это тестирование стоит достаточно дорого. В каком порядке вы 
проверяли бы даты после самого очевидного случая — 1 января 2000 года? 


б) Как бы вы протестировали стандартную функцию се 1те, возвращающую стро- 
ковое представление даты в следующей форме: 


Ег1 Пес 31 23:58:27 ЕЗТ 1999\п\0 


Предположим, что функция се 1ще вызывается из вашей программы. Как бы вы 
защитили ваш код от возможной некорректной реализации этой функции? 


в) Опишите процесс тестирования программы-календаря, выводящей результат в 
следующем виде: 


Јапоагу 2000 

5 МТ ИТЬ Е $5 

1 

2 334 Бе в 

95:20:22. 125181415 

16 17 18 19 2021 22 

23 24 25 26 27 28 29 
30 31 


г) Какие еще даты являются ключевыми в системах и программах, которыми вы 
пользуетесь, и как бы вы протестировали корректность работы с ними? 
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6.2. Систематическое тестирование 


Очень важно тестировать программу по строгой системе, четко представляя себе 
на каждом шаге, что именно тестируется и какие результаты должны быть получе- 
НЫ. Необходимо соблюдать порядок и последовательность, чтобы ничего не пропус- 
тить, и вести записи, чтобы не забыть, какая часть работы уже проделана. 


Тестируйте маленькими шажками. Тестирование должно идти параллельно с 
выстраиванием структуры программы. Тестирование всей программы сразу, после 
ее написания, отнимает гораздо больше времени и усилий, чем пошаговое. Напиши- 
те часть программы, протестируйте ее, добавьте немного нового кода, опять протес- 
тируйте и т.д. Если у вас имеется два пакета модулей, которые пишутся и тестиру- 
ются независимо, проведите их тестирование тогда, когда придет время соединить 
их в одно целое. 

Например, когда мы тестировали программу СЗУ (см. главу 4), первый шаг 
состоял в том, чтобы написать ровно столько кода, сколько требуется для чтения 
входных данных. Это позволило проверить корректность ввода данных и их 
предварительной обработки. Следующим шагом было разбиение входных строк по 
запятым. Как только эти части заработали правильно, мы перешли к работе с полями 
в кавычках, а затем постепенно дошли до тестирования всей программы. 


Начинайте тестирование с самых простых случаев. Пошаговый подход 
применим также и к выбору последовательности программных средств, которые 
следует протестировать. Вначале следует сосредоточить внимание на самых простых 
частях программы, составляющих ее основное, рутинно выполняемое тело. Только 
убедившись в правильности их работы, следует двигаться дальше. Таким образом, на 
каждом этапе тестированию подвергается все самое главное, и постепенно накап- 
ливается уверенность, что основные механизмы программы работают надежно. 
Простые ошибки обнаруживаются простыми тестами. Каждый тест вносит свой 
небольшой вклад в устранение следующей потенциальной проблемы. Хотя каждую 
следующую ошибку труднее заставить произойти, чем ее предшественницу, это не 
обязательно означает, что ее труднее исправить. 

В этом разделе мы поговорим о выборе эффективных тестов и порядке их выпол- 
нения; в следующих двух — о механизации процедуры тестирования, чтобы ее мож- 
но было выполнять с высокой производительностью. Первым шагом, по крайней 
мере для небольших программ или отдельных функций, является обобщение про- 
верки предельных случаев и граничных условий, которые рассматривались в преды- 
дущем разделе, — систематическое тестирование простых случаев. 

Предположим, есть функция, выполняющая двоичный поиск в массиве целых 
чисел. Следует начинать с таких тестов в порядке их усложнения: 


е поискв массиве, вообще лишенном элементов; 

®_ поиск в массиве из одного элемента по ключу, который: 
* меньше, чем единственный элемент в массиве; 
* равен единственному элементу; 
* больше, чем единственный элемент; 
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® поиск В массиве из двух элементов по ключам, которые: 
* охватывают все пять возможных случаев; 


® проверка корректности поиска в массиве с одинаковыми элементами по клю- 
чам, которые: 


* меньше, чем значение в массиве; 
* равны этому значению; 
* больше этого значения; 
® поиск В Массиве из трех элементов в таком же режиме, как из двух; 
® поискв массиве из четырех элементов в таком же режиме, как из двух и трех. 


Если функция пройдет все эти тесты и не потерпит крах, то скорее всего она ра- 
ботает нормально, однако дальнейшее тестирование все же не исключается. 

Описанный набор тестов достаточно невелик, чтобы его можно было выполнить 
от руки, но все-таки лучше написать небольшую программу автоматизированного 
тестирования, механизирующую этот процесс. Приведенная ниже программа на- 
столько проста, насколько это вообще возможно. Она считывает строки, содержащие 
ключ поиска и размер массива, затем создает массив указанной длины из чисел 
1, 3, 5,..., и разыскивает заданный ключ в массиве. 


/* ріпсеѕє таіп: автоматизированное тестирование ріпѕеагсһ */ 
іпё таіп (уоіа) 


{ 


106 і, Кеу, пе1етм, агг [1000]; 


хһі1е (ѕсапї ("#4 %4а", &Кеу, &пе1ет) != ЕОЕ) { 
Ғор (і = 0; і < пеїет; 1++) 
аух [1] = 2*1 + 1; 


ргіпсғ ("%Аа\п", ріпѕеагсһ (кеу, агг, пе1ет)); 


} 


гесигп 0; 


} 


Это довольно примитивная конструкция, но она демонстрирует, что полезная 
программа автоматизации тестирования не обязательно должна быть большой. 
Ее легко расширить и доработать так, чтобы она выполняла дополнительные тесты и 
требовала как можно меньшего объема ручной работы. 


Знайте, чего ожидать на выходе. При тестировании всегда необходимо знать, 
какой правильный ответ должен получиться на выходе программы; если он неизвес- 
тен, тестирование становится пустой тратой времени. На первый взгляд здесь все оче- 
видно. И действительно, по выходным данным многих программ можно сразу опреде- 
лить, работает программа или нет — например, является ли копия файла действитель- 
но точным его дубликатом или нет, выдает ли программа сортировки действительно 
отсортированный массив, и является ли он результатом перестановки исходного. 

Но большинство программ не поддается такому простейшему анализу. Напри- 
мер, как определить, выдает ли компилятор точный перевод исходного кода на язык 
ассемблера или машинных кодов? Дает ли численный алгоритм ответ в заданных 
границах точности? Помещает ли графическое приложение все пиксели на поло- 
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женные им места? В таких программах особенно важно найти способ сравнения 
результата с известным правильным ответом. 


е Для тестирования компилятора следует скомпилировать и запустить на выпол- 
нение тестовые файлы исходного кода. Эти тестовые программы должны выда- 
вать выходные данные, которые можно будет сравнить с известными ответами. 


• Для тестирования программы численного расчета постройте набор тестовых 
задач, охватывающих его предельные случаи, — как простейшие, так и более 
сложные. Везде, где это возможно, напишите код для анализа свойств выда- 
ваемых ответов. Например, при тестировании программы численного интегри- 
рования ответ следует проверять на непрерывность и на совпадение с извест- 
ными аналитическими решениями в замкнутой форме. 


• Чтобы протестировать программу для работы с графикой, недостаточно нарисо- 
вать на экране прямоугольник; считайте данные этого прямоугольника с экрана 
и убедитесь, что его контур в точности удовлетворяет заданным условиям. 


Если программа преобразует данные в двух взаимно обратных направлениях, 
проверьте, может ли она в точности восстановить исходную информацию. Пример 
таких двух направлений — это шифровка и дешифровка данных. Если зашифрован- 
ные данные не удается расшифровать в их исходную форму, значит, что-то не так. 
Аналогично, взаимно обратными алгоритмами являются методы упаковки (сжатия) 
файлов и их распаковки. Если программа может упаковать набор файлов, она долж- 
на быть в состоянии распаковать их без потерь и искажений. Иногда обратную опе- 
рацию можно проделать несколькими способами; в таком случае протестировать 
нужно все эти способы. 


Проверяйте свойства сохранения. Многие программы при обработке данных 
сохраняют неизменными некоторые их свойства, которые бывает полезно проверить. 
Например, утилиты наподобие мс (для подсчета строк, слов и символов) или зат 
(для подсчета контрольной суммы) позволяют убедиться, что те или иные данные 
имеют одинаковый размер, одинаковое количество слов, содержат одни и те же бай- 
ты в том же порядке и т.п. Существуют программы, которые устанавливают иден- 
тичность файлов (стр) или, наоборот, генерируют список различий между ними 
(21#Ғ#). Эти программы или их аналоги имеются во многих операционных средах, 
и их стоит иметь под рукой. 

Программа подсчета частоты байтов, приведенная далее, может использоваться 
для проверки сохранности данных после обработки, а также для выявления анома- 
лий наподобие нетекстовых символов в текстовых файлах. Вот одна из версий этой 
программы, которую мы назвали Ёгед: 

#іпс1іџае <5ѕіаіо.Һ> 


#1пс1аае <сіёуре.Һ> 
#1пс1аае <1ітієѕ.Һ> 


цпѕідпеа 1опа соцпі [ОСНАВ_МАХ+1]; 


/* Ехеа таіп: подсчет частоты байтов */ 
1106 таіп (уоіа) 
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106 с; 


м511е ((с = деєсһаг ()) != ЕОЕ) 
соцпе [с] ++; 


Ғор (с = 0; с <= ОСНАВ МАХ; с++) 


1Е (соцпё [с] != 0) _ 
ргіпёЁ ("%.2х %с  %1а\п", 
с, іѕргіпіё (с) ? с : '-', соцпё [с]); 
гесигп 0; 


Внутри программы тоже можно проверять некоторые свойства сохранения. 
Тривиальная проверка самосогласованности состоит в том, чтобы подсчитать коли- 
чество элементов в структуре данных с помощью специальной функции. Например, 
хэш-таблица должна быть устроена таким образом, чтобы каждый помещенный в 
нее элемент можно было впоследствии извлечь. Это свойство можно проверить, вве- 
дя в программу функцию, выводящую все содержимое таблицы в файл или массив. 
В любой момент времени количество вставок в таблицу минус количество удалений 
из нее должно равняться количеству оставшихся элементов, и это условие достаточ- 
но легко проверить. 


Сравнивайте независимые реализации. Независимые друг от друга реализации 
одной и той же библиотеки или программы, очевидно, должны давать одинаковые 
результаты. Например, два компилятора должны транслировать одну и ту же про- 
грамму в исполняемые модули, которые бы вели себя одинаково в одной и той же 
выполняющей среде, по крайней мере, в большинстве ситуаций. 

Иногда ответ можно вычислить двумя различными способами или же написать 
очень простую (до тривиальности) версию программы, которая делает то же самое, 
только медленно и нерационально; такая версия используется для независимого 
сравнения. Если две независимо разработанные программы дают один и тот же от- 
вет, то они, скорее всего, работают правильно. Если же ответы различаются, то по 
крайней мере в одной из программ есть ошибка. 

Один из авторов как-то раз разрабатывал компилятор для новой среды вместе с од- 
ним из сотрудников. Работа по отладке кода, генерируемого компилятором, была рас- 
пределена: один человек писал программу, которая кодировала инструкции для вы- 
полняющей среды, а второй писал дизассемблер для отладчика. Вследствие этого было 
маловероятно дублирование любой ошибки в интерпретации или реализации набора 
инструкций сразу в двух компонентах. Если компилятор неправильно кодировал ту 
или иную инструкцию, дизассемблер обязательно это замечал. Все данные, получае- 
мые на выходе компилятора, прогонялись через дизассемблер и сравнивались с отла- 
дочными данными, выдаваемыми самим компилятором. Этот подход оказался очень 
практичным и результативным; он позволил обнаружить и исправить много ошибок в 
обоих компонентах. Необходимость долгой и трудной отладки возникала лишь тогда, 
когда разработчики обоих компонентов одинаково неправильно интерпретировали 
двусмысленную фразу в спецификации архитектуры выполняющей среды. 
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Следите за полным охватом программы при тестировании. Одна из задач 
тестирования заключается в том, чтобы в процессе прогона тестов заставить выпол- 
ниться каждый оператор программы. Тестирование не может считаться полным, ес- 
ли каждая строка программы не была выполнена хотя бы один раз. Подобного пол- 
ного охвата при тестировании бывает не так-то легко добиться. Даже оставляя в сто- 
роне непредсказуемые ситуации, которые в нормальных условиях не возникают, 
бывает непросто заставить программу выполнить определенные операторы, задавая 
ей те или иные исходные данные. 

На рынке программного обеспечения имеются готовые программы для измере- 
ния частоты выполнения отдельных частей программы. Это программы профилиро- 
вания, которые часто входят в состав пакетов компиляторов или сред разработки и 
предоставляют возможность подсчитать частоту выполнения любых операторов 
программы. Это дает возможность определить, насколько полный анализ выполняе- 
мости программы дает тот или иной тест. 

Мы протестировали программу из главы 3 для генерирования текста по алгорит- 
му марковских цепей, используя комбинацию всех перечисленных методов. Эти тес- 
ты подробно описаны в последнем разделе данной главы. 


Упражнение 6.3. Предложите процедуру тестирования для программы Ётеч. 


Упражнение 6.4. Спроектируйте и реализуйте версию программы Ёгед, подсчи- 
тывающую частоты употребления других, не символьных, данных, — таких как 
32-разрядные целые или вещественные числа. Можно ли сделать так, чтобы одна и 
та же программа просто и удобно выполняла одну и ту же операцию над разными 
данными? 


6.3. Автоматизация тестирования 


Выполнять большой объем тестирования вручную, во-первых, скучно, во-вторых, 
ненадежно. При надлежащем тестировании нужно выполнить очень много тестов, 
задать очень много исходных данных и сравнить очень много результатов. Поэтому 
тестирование желательно переложить на программы, которые никогда не устают и 
не проявляют небрежности. Стоит потратить некоторое время и написать сценарий 
на командном языке или тривиальную программу, которая выполняет все необхо- 
димые тесты. После этого полный набор тестовых примеров можно будет запускать 
нажатием одной кнопки (в буквальном или переносном смысле). Чем легче запус- 
кать набор тестов на выполнение, тем чаще это можно делать и тем меньше вероят- 
ность пропустить что-нибудь, если время будет поджимать. Мы написали тестовую 
программу, тестирующую весь код, написанный для этой книги, и запускали ее вся- 
кий раз, когда в код вносились какие-либо изменения. Отдельные части этого теста 
запускались автоматически после каждой успешной компиляции. 


Автоматическое регрессионное тестирование. Начинать автоматизацию 
следует с регрессионного тестирования — последовательности тестов, сравнивающих 
новую версию какой-либо программы с ее же предыдущей версией. При исправле- 
нии ошибок и устранении проблем программисты имеют тенденцию тестировать 
только исправленные фрагменты кода, упуская из виду возможность того, что это же 
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самое исправление испортило что-то в другой части программы. Назначение регрес- 
сионного тестирования состоит как раз в том, чтобы гарантировать неизменную ра- 
боту всех функций программы, кроме добавленных. 

В некоторых системах средства для такой автоматизации имеются в изобилии. 
Так, языки разработки сценариев позволяют легко написать короткую тестовую 
процедуру для прогона набора тестов. В системе Ошх имеются утилиты сравнения 
файлов, аі## и стр, позволяющие анализировать выходные данные программ на 
совпадение с эталонными. Утилита ѕогі позволяет собирать родственные элементы 
данных вместе; утилита агер помогает отфильтровать выходные данные, а мс, зат 
и Егеа — резюмировать их. Все эти средства в совокупности позволяют быстро и 
эффективно разработать автоматизированные тестовые процедуры почти для любых 
программ, разработкой которых занимается один человек или небольшая группа. 
Правда, для тестирования больших программных проектов этих средств может 
оказаться недостаточно. 

Далее приведен сценарий регрессионного тестирования для программы под на- 
званием Ка. Этот сценарий запускает старую версию (о1а Ка), а затем новую 
(пем Ка) на большом количестве разных тестовых файлов и сообщает, если между 
выходными данными двух версий имеются различия. Он написан на языке команд- 
ной оболочки Отих, но его можно легко перевести на Рег! или другой язык разработ- 
ки командных сценариев. 


Гог і іп Ка_@Чака.* # цикл по тестовым файлам данных 
ао 

о1а Ка $1 >оцЕ1 # запуск старой версии 

пем Ка $1 >0ц62 # запуск новой версии 

1Е ! стр -ѕ оці оцё2 # сравнение выходных данных 

Сһеп 

есһо $1: ВАР # если разные, то ошибка 

Е1 

аопе 


Сценарий тестирования обычно должен выполняться “молча”, выводя какую-то 
информацию только в том случае, если происходит что-то неожиданное. Именно так 
работает приведенный сценарий. Вместо этого можно было бы выводить имя каждого 
обрабатываемого файла, а после него — сообщение об ошибке, если таковая случается. 
Подобная индикация процесса помогает выявить, например, такую проблему, как за- 
цикливание или запуск не того теста в ходе выполнения сценария, но если тест выпол- 
няется правильно, излишняя информация на экране может раздражать пользователя. 

Аргумент -ѕ утилиты стр приказывает ей возвращать код сравнения, но не вы- 
водить никаких данных на экран. Если сравнение файлов показывает их совпадение, 
то возвращается код “истина”, выражение ! стр ложно и на экран ничего 
не выводится. Если же выходные данные старой и новой версий программы 
отличаются, то утилита стр возвращает код “ложь” и выводятся имя файла и преду- 
преждающее сообщение. 

При выполнении регрессионного тестирования делается неявное предположение 
о том, что старая версия программы вычисляет правильный ответ. То, что это дейст- 
вительно так, следует очень скрупулезно проверить в самом начале работы над про- 
граммой и затем тщательно поддерживать такое положение дел. Если в регрессион- 
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ный тест закрадется неправильный ответ, обнаружить его будет не так-то просто, 
а вся информация, базирующаяся на нем, окажется искаженной. Полезно время от 
времени выполнять тщательную проверку самого регрессионного теста, чтобы лиш- 
ний раз убедиться в его правильности. 


Самодостаточные тесты. В дополнение к регрессионному тестированию сле- 
дует составить набор самодостаточных тестов, в состав которых входят исходные 
данные и эталонные результаты. Поучительным примером может служить наш опыт 
по тестированию интерпретатора А\К. Многие конструкции языка А\К тестирова- 
лись таким образом: определенные данные прогонялись через маленькие програм- 
мки на этом языке, а затем результаты сравнивались с эталонными. Ниже приведен 
фрагмент большого набора тестов, предназначенный для проверки работы одного 
хитроумного выражения инкрементирования. В этом тесте новая версия интерпре- 
татора АМК (пемамк) выполняется над короткой программой. Результат работы но- 
вой версии записывается в один файл, эталонный результат — в другой; затем файлы 
сравниваются, и выдается сообщение об ошибке, если они не совпадают. 


# тест инкрементирования поля: $1++ означает ($1)++, а не $(1++) 
есһо 3 5 | пемамк '{1 = 1; ре1фпЕ $1++; ргіпё $1, 1}' >о0461 


еспо '3 4 1' >04Е2 # правильный ответ 
1Е ! стр -$ оцё1 оцЕ2 # различные данные на выходе 
СВеп 


есһо 'ВАШР: Ғіе1а іпсгетепі безі Ёа11еа' 
Е1 

Первый комментарий является частью теста. В нем сообщается и документирует- 
ся, какие именно возможности тестируются. 

Иногда удается построить большое количество тестовых примеров сравнительно 
небольшими усилиями. Для целей анализа простых выражений мы создали простой 
узкоспециализированный язык описания тестов, исходных данных и ожидаемых 
результатов. Ниже приводится короткое описание небольшого теста, который про- 
веряет корректность некоторых способов представления числа 1 вязыке А\К. 


Егу (1Е ($1 == 1) ргіпё "уеѕ"; е1зе рк1пе "по"} 
1 уез 
1.0 уез 
1Е0 уез 


0.1Е1 уеѕ 
10Е-1 уеѕ 


01 уез 
+1 уеѕ 
10Е-2 по 
10 по 


Первая строка представляет собой тестируемую программу (все, что идет после 
слова гу). В каждой последующей строке приведены исходные данные и ожидае- 
мые результаты, разделенные символами табуляции. В первом тесте говорится, что 
если первое поле исходных данных равно 1, то на выходе программа должна сооб- 
щить уез. Первые семь тестов дают результат уез, а последние два — по. 

Программа на языке АмК (а как же иначе!) преобразует каждый тест в полную 
программу на языке А\К, затем запускает ее на выполнение с каждым набором 
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входных данных и сравнивает результаты с эталонными. Какая-либо информация 
выводится на экран только тогда, когда выдается неправильный ответ, не совпадаю- 
щий с эталонным. 

Аналогичные механизмы используются для тестирования команд поиска по регу- 
лярным выражениям и замены/подстановки. Специальный язык для написания тестов 
(пусть даже примитивный) позволяет с удобством сгенерировать множество тестовых 
примеров. Создание программы для написания другой программы с целью тестирова- 
ния третьей программы — это своеобразный рычажный механизм, позволяющий серь- 
езно увеличить первоначально приложенное усилие. (В главе 9 о таких языках и про- 
граммах, которые пишут другие программы, рассказывается более подробно.) 

В целом мы разработали около тысячи тестов языка АмК, причем весь этот набор 
можно было запустить одной командой. Если все шло хорошо, на экран вообще ничего 
не выводилось. Как только в язык добавлялась новая возможность или в нем исправ- 
лялась ошибка, тут же разрабатывались новые тесты, позволявшие проверить их кор- 
ректную работу. При каждом изменении программы, даже тривиальном, запускался 
весь набор тестовых примеров; его выполнение отнимало всего несколько минут. 
В результате иногда удавалось “поймать” совершенно неожиданные ошибки, а в целом 
этот набор тестов неоднократно спасал авторов языка АК от публичного позора. 

Что же делать, когда оказывается, что в программе есть ошибка? Если ее не обна- 
руживает ни один из имеющихся тестов, следует разработать новый тест и прове- 
рить его на ошибочной версии кода. Обнаруженная ошибка может дать идеи для 
дальнейших тестов или совершенно новых классов проверок. Иногда бывает доста- 
точно добавить в программу средства защиты, перехватывающие и обрабатывающие 
ошибку внутри нее. 

Сохраняйте все имеющиеся у вас тесты. С их помощью можно определить, опи- 
сывает ли отчет об ошибке в очередной версии программы действительную ситуа- 
цию или она уже давно исправлена. Ведите записи об ошибках, изменениях и ис- 
правлениях; это поможет вспомнить старые проблемы и исправить новые. В боль- 
шинстве организаций по разработке программного обеспечения это обязательный 
элемент рабочего процесса. Но если даже вы программируете для себя, такие записи 
все равно стоит делать, потому что времени это отнимает немного, а положительный 
результат налицо. 


Упражнение 6.5. Разработайте набор тестовых примеров для тестирования 
функции ре1 пе Е, применяя как можно больше средств автоматизации. 


6.4. Тестирование компонентов 
в программных оболочках 


До сих пор наше изложение было посвящено тестированию законченных авто- 
номных программ. Но это не единственный способ автоматизированного тестирова- 
ния, как и не самый удобный метод тестирования частей большой программы в про- 
цессе ее разработки, особенно если такая разработка выполняется на коллективной 
основе. Неудобен этот способ и тогда, когда необходимо протестировать небольшой 
компонент, встроенный в большую систему. 
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Чтобы протестировать отдельный компонент, для него обычно приходится пи- 
сать некую программную оболочку, содержащую достаточно средств интерфейса, 
чтобы компонент мог выполняться корректно. Ранее в этой главе уже демонстриро- 
валась самая примитивная оболочка такого вида для тестирования функции двоич- 
ного поиска. 

Достаточно легко написать нечто подобное и для тестирования таких компонен- 
тов, как математические функции, строковые функции, процедуры сортировки и т.п., 
поскольку все, что необходимо сделать в оболочке, — это задать входные параметры, 
вызвать функцию и сравнить результат с эталоном. А вот чтобы протестировать 
таким образом частично незавершенную программу, требуется больше усилий. 

Для иллюстрации сказанного пройдем все этапы построения программной обо- 
лочки для тестирования функции метзее, одной из функций семейства тет... 
стандартной библиотеки С/С++. Эти функции часто пишутся на языке ассемблера 
для конкретной выполняющей среды, поскольку большое значение имеет их быст- 
родействие. Чем больше их оптимизируют при разработке, тем больше вероятность 
ошибки и тем тщательнее необходимо их тестировать. 

Первый шаг — это написать самую простую, но гарантированно работающую 
версию на языке С. Она даст возможность сравнения по быстродействию и, что еще 
важнее, образец правильной работы. При переходе в новую выполняющую среду 
переносится именно простейшая версия, а затем уже выполняются все оптимизации, 
пока не будет достигнуто нужное качество. 

Функция тетзек (5,с,п) делает п байт памяти равными заданному байту с, 
начиная с адреса ѕ, после чего возвращает ѕ. Если не заботиться о быстродействии, 
то написать такую функцию проще простого: 


/* шешзее: делает п байт по адресу ѕ равными с */ 
уоіа *тетзее (уоіа *5, 116 с, 5312е_ п) 


ѕіле Ё і; 
сһаг *р; 


р = (сһаг *) в; 

Ғог (і = 0; і < п; 1++) 
рії] = с; 

геёцүп 8; 


} 


Но если соображения быстродействия играют решающую роль, то используются 
такие приемы, как запись целых 32- или 64-разрядных слов. При оптимизации таких 
операций часто возникают ошибки, поэтому необходимо самое тщательное тестиро- 
вание. 

Тестирование основывается на сочетании проверки предельных случаев и пере- 
бора вариантов в потенциально опасных местах программы. Для функции тетзее к 
предельным случаям относятся значения п, равные, во-первых, тривиальным числам 
нуль, один или два, во-вторых, степеням двойки и близлежащим числам. Это могут 
быть как маленькие, так и довольно большие числа, — например, 2", соответствую- 
щее естественному пределу во многих выполняющих средах с 16-разрядным словом. 
Степени двойки заслуживают внимания по той причине, что один из способов уско- 
рить работу функции метзе* — это записывать сразу по несколько байт за один раз. 
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Для этого используются специальные машинные инструкции или запись целых слов 
вместо отдельных байтов. Аналогично, необходимо проверить различные способы 
размещения начала массива в памяти с различным выравниванием; это позволяет 
обнаружить ошибки, связанные с начальным адресом или длиной. Мы поместим 
основной массив в более длинный, таким образом создавая буферную зону или по- 
лосу безопасности с каждой его стороны, чтобы иметь возможность легко варьиро- 
вать выравнивание. 

Также необходимо проверить целый ряд значений аргумента с, в том числе нуль, 
0х7Е (самое большое значение со знаком в 8-разрядных байтах), 0х80 и ОхЕЕ 
(провокации на ошибку обработки символов со знаком и без знака), а также 
несколько чисел, значительно больших, чем помещаются в один байт (чтобы убе- 
диться, что действительно используется только один байт). Следует также инициа- 
лизировать буфер памяти некоторым известным эталонным значением, отличаю- 
щимся от всех перечисленных, чтобы проверить, записывает ли функция тетзеЕ 
данные за пределами заданного массива. 

Простейшую реализацию функции можно использовать как стандарт для срав- 
нения в таком тесте, в котором в памяти размещаются два массива, а затем сравнива- 
ется работа функции с различными комбинациями п и с при нескольких возможных 
смещениях внутри массива: 

рід = макс. левое поле + макс. п + макс. правое поле 

50 = та11ос (рід) 

51 = ма11ос (рід) 

для каждой комбинации п, с и смещения оЁЕЁзеф: 
записать в $0 и $1 известный образец 
выполнить медленную метзее (50 + оЁЁѕеі, с, п) 
выполнить быструю петѕеб (50 + оЕЁзеф, с, п) 


проверить возвращаемые значения 
сравнить $0 и $1 побайтово 


Если в результате ошибки функция тетзее запишет что-нибудь за пределами 
заданного массива, то это скорее всего случится в начале или в конце буфера, так что 
наличие буферной зоны позволяет легко отследить поврежденные байты, а также 
снизить вероятность повреждения других частей программы. Чтобы выявить запись 
за пределами заданного буфера, мы сравниваем все байты массивов 50 И 51, 
а не только те п байт, которые функция должна записывать. 

Итак, разумно достаточный набор тестов должен включать проверку всех комби- 
наций следующих значений: 

ОЕЕЗеЕ. = 10, 11; 3... -20 

с =0, 1, ОХ7Е, 0х80, ОХРЕ, 0х11223344 

Ооу ау а Ба ВӘ ль, Чет, 
31, 32, 33, ..., 65535, 65536, 65537 


Значения п должны охватывать как минимум 2'- 1, 2 и 2' + 1 для і от 0 до 16. 
Все эти числа не стоит перечислять в теле тестовой программной оболочки, а вместо 
этого включить в массивы, создаваемые от руки или автоматически. Лучше сгенери- 
ровать их автоматически; в этом случае легче задать больше степеней двойки, вари- 
антов смещений и символов. 
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Эти тесты позволят полностью проанализировать работу тетзее, при этом не 
отнимая много времени даже на их создание, не говоря уже о выполнении. Всего 
описанный тестовый набор содержит около 3500 тестов. Все они полностью перено- 
симы в другие операционные среды. 

В качестве предупреждения расскажем следующую историю. Как-то раз мы 
передали копию тестовой программы и набора для тшетзее разработчику одной опе- 
рационной системы и библиотек для нового процессора. Несколько месяцев спустя 
мы (авторы исходного теста) начали пользоваться этой системой и вдруг обнаружи- 
ли, что большая программа терпит крах при прогоне ее набора тестов. Мы проследи- 
ли источник проблемы до крохотной ошибки, связанной со знаком в реализации 
функции тетѕеб на языке ассемблера. По неизвестной причине разработчик биб- 
лиотеки изменил процедуру тестирования шетзе® так, что она перестала проверять 
значения с больше 0х7Е. Разумеется, ошибка была локализована путем выполнения 
исходного, правильного набора тестов, как только мы поняли, что главным подозре- 
ваемым является функция тетѕеё. 

Такие функции, как метзее, поддаются исчерпывающему тестированию мето- 
дом перебора, поскольку достаточно просты, и можно доказать, что тестовые данные 
обеспечивают перебор всех возможных путей выполнения. Например, функцию 
теттоуе можно протестировать на все возможные комбинации наложения, пере- 
мещения и выравнивания буферов памяти. Это не есть перебор в точном смысле это- 
го слова, поскольку не перебираются все возможные операции копирования, однако 
в тестовом наборе представлены все существенно различные ситуации. 

Разумеется, как и в других случаях, программная оболочка должна содержать пра- 
вильные ответы, с которыми сравниваются выходные данные тестируемого модуля. 
Важный метод, использованный нами при тестировании функции метзек, заключает- 
ся в том, чтобы сравнивать работу новой оптимизированной версии (возможно, оши- 
бочной) с работой простейшей функции, в правильности которой мы уверены. 
Это можно делать в несколько этапов, как показывает описанный ниже пример. 

Один из авторов занимался разработкой библиотеки для работы с растровой 
графикой. В ней применялась операция копирования блоков пикселей из одного 
изображения в другое. В зависимости от заданных параметров это могло быть про- 
стое копирование буферов памяти или же копирование с преобразованием из одной 
цветовой кодировки в другую; возможно было также “мозаичное” копирование, при 
котором фрагмент многократно дублировался в прямоугольной области, а также 
любые комбинации этой техники и нескольких других. Спецификация этой опера- 
ции выглядела просто, а вот для эффективной ее реализации требовалось написать 
много специализированного кода для самых разных случаев. Проверка правильно- 
сти работы всего этого кода потребовала специальной стратегии тестирования. 

Вначале вручную была написана небольшая простая процедура, выполняющая 
данную операцию правильно над одним пикселем. Она использовалась для провер- 
ки того, как библиотека справляется с обработкой одного пикселя. После заверше- 
ния этого этапа можно было быть уверенным, что с одним пикселем дела обстоят 
нормально. 

Затем была написана процедура для работы с одной горизонтальной строкой 
пикселей. Она вызывала библиотечные функции для обработки одного пикселя за 
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раз, поэтому работала очень медленно. Результаты ее работы сравнивались с резуль- 
татами, выдаваемыми гораздо более быстродействующей библиотечной процедурой. 
Когда все прошло успешно, библиотеке можно было уже доверять и в работе с гори- 
зонтальными строками пикселей. 

Мы продолжали в том же духе: составили из строк прямоугольники, из прямо- 
угольников — мозаику и т.д. По ходу дела было найдено множество ошибок, в том чис- 
ле некоторые из них — в самой тестирующей программе. В этом и состояла сила мето- 
да: проверялись сразу два независимых компонента, и постепенно возрастало доверие 
к обоим. Если тест выполнялся неправильно, тестирующая программа выдавала под- 
робный отчет обо всех обработанных данных; с его помощью можно было проанализи- 
ровать правильность работы как библиотеки, так и самой тестирующей процедуры. 

Данная библиотека дорабатывалась и переносилась в другие среды еще много 
лет, и всякий раз тестирующая программа помогала находить и исправлять новые 
ошибки. Поскольку в ней применялся послойный, многоуровневый подход, ее необ- 
ходимо было каждый раз выполнять целиком, чтобы заодно проверять ее соответст- 
вие библиотеке. Так получилось, что выполняемое ею тестирование было не сплош- 
ным, а вероятностным: в ходе теста генерировались случайные тестовые данные, 
иони, накапливаясь за достаточно долгое время, позволяли протестировать бук- 
вально каждый оператор кода. Поскольку потенциальных тестовых данных могло 
быть очень много, эта стратегия оказалась намного эффективнее, чем построение 
тестового набора от руки или исчерпывающий перебор всех возможных тестовых 
примеров. 


Упражнение 6.6. Разработайте тестирующую оболочку для функции тетѕеб 
согласно принципам, которые мы рассмотрели. 


Упражнение 6.7. Разработайте тесты для всех остальных функций семейства 
тет. ... 


Упражнение 6.8. Выберите режим тестирования для таких математических 
функций С, как зат, зіп и т.п., объявленных в заголовочном файле таєЬ.һ. Какие 
входные данные имеет смысл задавать для их тестирования? Какие независимые 
проверки можно (и нужно) выполнить? 


Упражнение 6.9. Разработайте механизмы для тестирования функций семейства 


ѕег... языка С, например зегспр. Некоторые из этих функций, особенно функ- 
ции выделения лексем ѕегсок или ѕегсѕрп, существенно сложнее, чем семейство 
тет. . .; соответственно, они требуют более сложного и тщательного тестирования. 


6.5. Стрессовое тестирование 


Один из эффективных методов тестирования состоит в том, чтобы “нагрузить” 
программу большим объемом исходных данных, сгенерированных автоматически. 
Такие данные вынуждают программу вести себя по-другому, чем в случае данных 
небольшого объема, введенных вручную. Большой объем данных сам по себе опасен, 
поскольку из-за него переполняются буферы, массивы, счетчики и т.п.; это позволяет 
обнаружить в программе места, где размеры структур данных сделаны фиксирован- 
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ными или не контролируются должным образом. Пользователь-человек имеет тен- 
денцию избегать “невозможных” случаев наподобие пустых потоков ввода, числовых 
данных, выходящих за пределы заданного диапазона, слишком длинных имен или 
несообразно больших значений параметров. А вот компьютерные программы гене- 
рируют исходные данные в строгом соответствии с заданным алгоритмом, без вся- 
ких попыток уклониться от ТОЙ ИЛИ ИНОЙ конкретной ситуации. 

Для иллюстрации ниже приведена одна строка данных, сгенерированных компи- 
лятором М1сгозой Міѕџа] С++ версии 5.0 при трансляции ЅТІ-варианта программы 
пагКоу. Строка отредактирована так, чтобы помещаться на страницу. 

хегее (114) : магп1п9 С4786: '56а::_Ткее<з%А: :аечце<в(@: : 

раѕіс ѕбгіпд<сһаг, 56а: :спаг_6га1е5<сНах>, 564: :а11осаіог 

<сВаг>>, з(4: :а11осабог<5Еа: :раз1<_зЕх1п9<срвахг, 864: : 

опущено 1420 символов 


а11осабох<сваг>>>>>>: :16екабог' : ідепііҒіег маѕ 
Єгипсабеа бо '255' сһагасёегѕ іп ёһе ерид 1пЕогтае1оп 


Компилятор предупреждает, что он сгенерировал имя переменной, имеющее 
невероятную длину 1594 символа, но в отладочной информации сохранил только его 
первые 255 символов. Далеко не все программы способны обезопасить себя от нега- 
тивного влияния строк подобной длины. 

Задание случайных наборов входных данных (не обязательно корректных) — 
это еще один способ агрессивной атаки на программу в надежде сломить ее сопро- 
тивление. Это делается вместо того, чтобы рассуждать на тему “нормальные люди 
так не поступают”. Например, некоторые коммерческие компиляторы С тестирова- 
лись с помощью сгенерированных случайным образом, но синтаксически правиль- 
ных исходных текстов. Прием здесь состоит в том, чтобы взять спецификацию дан- 
ных — в данном случае стандарт языка С — и написать программу, генерирующую 
данные в соответствии с этой спецификацией, но по случайной схеме. 

Такие тесты рассчитаны скорее на проверку встроенных в программу средств 
контроля и самозащиты, а не на сравнение полученных ответов с эталонными; их 
целью является спровоцировать крах программы или “невозможную” ситуацию, а не 
обнаружить ошибки в алгоритме. Они же являются хорошим средством для провер- 
ки встроенных механизмов обработки ошибок. Если исходные данные имеют разум- 
ный характер, большая часть ожидаемых ошибок выполнения не случается и код для 
их обработки бездействует; однако именно в таких углах в основном и прячутся ал- 
горитмические ошибки. Правда, на каком-то этапе подобное тестирование может 
стать нерациональным — вынуждаемая к жизни ошибка оказывается столь редкой и 
маловероятной, что, возможно, вообще не стоит тратить время на ее исправление. 

В некоторых случаях тестирование выполняют с преднамеренно испорченными 
исходными данными. Так, удары по системам компьютерной безопасности часто 
наносятся с помощью объемистых или некорректных данных, которые затирают не- 
обходимую информацию. Эти слабые места необходимо обнаруживать и исправлять. 
Некоторые стандартные библиотечные функции легко уязвимы против подобных 
атак. Например, стандартная функция дебѕ не предусматривает никакого способа 
ограничить размер вводимой строки, поэтому ею вообще не стоит пользоваться. 
Чтобы не иметь проблем, вместо нее используйте конструкцию Ёдеёѕ (Ьцғ, 
БілеоЁ (раЁ), зЕа1п). Точно так же не ограничивает длину входной строки вы- 
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зов функции зсапЕ ("%5", риѓ), поэтому его следует заменить на вызов с явной 
спецификацией длины строки, например эсапЕ ("%205", роғ). В разделе 3.3 бы- 
ло показано, как справиться с этой проблемой в общем случае для буфера произ- 
ВОЛЬНОЙ ДЛИНЫ. 

Любая программа или функция, получающая данные снаружи (прямо или кос- 
венно), должна проверять введенные значения прежде, чем начинать их использо- 
вать. Следующая программа взята из учебника. Она считывает целое число, введен- 
ное пользователем, и выдает предупреждение, если это число слишком длинное. 
Цель программы — продемонстрировать решение проблемы с функцией деез, хотя 
предложенное решение не всегда работает. 


#АаеЁ1пе МАХМОМ 10 
106 таіп (уоіа) 
сһагу пит [МАХМОМ] ; 


петѕеѓ (пам, 0, зѕізеої (пит)); 
ргіпіЁ ("Туре а патрег: "); 
дез (пит) ; 
1Е (пот [МАХМОМ-1] != 0) 

ргіпеѓ ("Мотрег боо рід. \п"); 
/*... */ 


хо ооюоюоюоооо 


} 


Если введенное число имеет длину десять цифр, оно затрет последний нуль в 
массиве некоторым ненулевым значением, и теоретически эту ситуацию можно бу- 
дет распознать после возвращения из функции деб ѕ. К сожалению, этих мер безо- 
пасности недостаточно. Злонамеренный хакер может ввести еще более длинную 
строку, которая затрет критически важные данные, — например, адрес возврата из 
функции, — и тем самым заставит программу не возвратиться в тело оператора і, 
а выполнить какую-то другую процедуру, возможно, с разрушительными последст- 
виями. Таким образом, подобная небрежность при проверке исходных данных соз- 
дает брешь в системе безопасности. 

Не подумайте, что это всего лишь искусственный пример из учебника. В июле 
1998 года ошибка этого типа была обнаружена в нескольких широко распространен- 
ных программах электронной почты. Вот что писали в газете №ем УотЁ Тітеѕ: 


Брешь в системе безопасности возникла из-за так называемого “переполнения 
буфера”. Программистам обычно вменяется в обязанность включать в свои про- 
граммы проверку исходных данных на соответствие типов и длин наборов дан- 
ных. Если набор данных имеет слишком большую длину, он может переполнить 
“буфер” — участок памяти, выделенный для него. В этом случае программа элек- 
тронной почты может потерпеть крах, а злонамеренный программист — запус- 
тить вместо нее какую-либо вредоносную программу. 
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Именно так была организована одна из атак знаменитого “Іпѓегпеѓ-червя” в 1988 г. 

Программы, выполняющие синтаксический анализ данных из форм НТМГ, так- 
же могут оказаться уязвимыми для слишком длинных строк, помещаемых в корот- 
кие массивы: 


ѕёаёіс сһаг *ацеку [1024]; 


сһаг *геаа_Еоги (уо1а) 


{ 


106 а317е; 


4512е = або] (дебепу ("СОМТЕМТ ЪЕМСТН")); 
Егеаа (аоегу, а312е, 1, зѕіаіп); 
гесиги ацегу; 


хо 


} 


В этом коде неявно предполагается, что входная строка никогда не превысит 
длину 1024 байта. Поэтому данная функция, как и деез, подвержена атакам посред- 
ством переполнения буфера. 

Неприятности могут возникнуть и из-за более простых видов переполнения. 
Например, незамеченное переполнение целочисленной переменной может привести 
к катастрофическим последствиям. Рассмотрим следующее распределение памяти: 


? сһаг *р; 
2 р = (сһаг *) та11ос(х * у * 2); 


Если произведениех * у * 2 дает переполнение целочисленного диапазона, то 
вызов функции та11ос может, в принципе, привести к выделению буфера памяти 
вполне разумной, ограниченной длины, однако выражение р [х] при этом может 
ссылаться на участок памяти за его пределами. Предположим, что тип іп является 
16-разрядным, а х, уи 2 равны 41. Произведение х*у* 2 равно 68921, что при деле- 
нии на 2" дает остаток 3385. Таким образом, при вызове функции та11ос будет вы- 
делен буфер длиной всего 3385 байт и любое обращение к элементу за пределами 
этого буфера окажется ошибочным. 

Еще одним источником ошибок переполнения является преобразование типов. 
Простой перехват ошибки может оказаться недостаточным для решения проблемы. 
Так, в июне 1996 года взорвалась в испытательном полете ракета “Агіапе-5”, потому 
что пакет ее навигационного программного обеспечения был перенесен с “Агіапе-4” без 
должного тестирования. Новая ракета летела значительно быстрее, и в результате не- 
которые переменные накапливали гораздо большие значения, чем ранее. Вскоре после 
запуска попытка преобразовать 64-разрядное вещественное число в 16-разрядное це- 
лое со знаком привела к переполнению. Ошибка была замечена, но модуль-обработчик 
принял решение прекратить работу навигационной подсистемы. В результате ракета 
сошла с курса и взорвалась. По несчастливому совпадению аварийно завершившийся 
код генерировал инерциальные поправки, необходимые только до взлета; если бы этот 
модуль отключился в момент запуска, ракета полетела бы нормально. 

Если говорить о более повседневных проблемах, часто бывает, что двоичные 
входные потоки вынуждают аварийное завершение программ, ожидающих на входе 
текстовых данных, особенно если они работают с 7-разрядным подмножеством 
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кодировки АЅСП. Бывает весьма поучительно (и иногда отрезвляюще) подвергнуть 
ничего не подозревающую программу, которая ожидает текстовых данных, стрессу в 
виде двоичного входного потока, например кода скомпилированной программы. 

Хорошие тестовые примеры часто можно применить сразу к нескольким про- 
граммам. Например, всякую программу, считывающую файлы, следует тестировать 
на пустом файле. Любую программу, читающую и обрабатывающую текстовые стро- 
ки, необходимо тестировать на очень длинных и пустых строках, а также на входном 
потоке, вообще не разделенном на строки. Полезно иметь под рукой такой набор 
файлов, чтобы тестировать любые программы, не создавая всякий раз эти тесты за- 
ново. Или же напишите программу, которая по заказу будет сама генерировать необ- 
ходимый набор тестовых файлов. 

Когда Стив Борн (Ѕіеуе Воигпе) разрабатывал командную оболочку Ох 
(которая со временем стала известна как “среда Борна”, “Воигпе зЪе|”), он создал 
каталог из 254 файлов с именами, состоящими из одного символа. Были представле- 
ны все символы стандартной кодировки, кроме '\0' и косой черты, которые не мо- 
гут фигурировать в именах файлов Опіх. Далее он пользовался этим каталогом для 
всевозможных тестов, касающихся считывания лексем и поиска по заданным образ- 
цам. (Сам каталог с файлами был, разумеется, автоматически сгенерирован про- 
граммой.) Многие годы после своего создания этот каталог был проклятием для 
программ, считывающих или отображающих деревья файлов и каталогов, заставляя 
их терпеть крах или работать некорректно. 


Упражнение 6.10. Постарайтесь создать такой файл, который бы привел к ава- 
рийному завершению ваш любимый текстовый редактор, компилятор или другую 
подобную программу. 


6.6. Полезные советы 


Опытные тестировщики пользуются многими приемами для повышения произ- 
водительности своего труда. В этом разделе приведены некоторые из наших люби- 
мых трюков и подходов. 

В программах следует проверять соответствие индексов границам массивов (если 
язык сам не обеспечивает автоматическую проверку таких вещей); однако до выпол- 
нения самого проверяющего кода дело может и не дойти, если размер массива велик 
по сравнению с типичной длиной исходных данных. Чтобы выполнить проверку, 
временно сделайте размеры массивов достаточно малыми; так будет легче построить 
соответствующие тестовые примеры. Аналогичный прием использовался нами в ко- 
де для работы с растущими массивами из главы 2, а также в библиотеке СЗУ из гла- 
вы 4. Там мы оставили небольшие, тестовые значения размеров, поскольку затраты 
на инициализацию были незначительными. 

Заставьте хэш-функцию возвращать один и тот же хэш-код, чтобы все элементы 
помещались в одну ячейку таблицы. Это будет эффективным тестом механизма свя- 
зывания в цепочки, а также проверкой предельного, наихудшего случая. 

Если в вашей программе используется собственная функция распределения 
памяти, напишите такую ее версию, которая через некоторое время перестанет рабо- 
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тать. Это позволит протестировать код на устойчивость к ошибкам распределения 
памяти и выхода за пределы выделенных буферов. Следующая версия возвращает 
МО после 10 вызовов: 


/* Сеѕзёта110ос: возвращает М после 10 вызовов */ 
уоій *ЕезЕта11ос (512е_ п) 


ѕзіабіс іп соцпі = 0; 


1Е (++соцпЕ > 10) 
гебигп МО; 

е1зе 
гебогп ма11ос(п); 


Прежде чем распространять готовую программу, уберите все тестовые ограниче- 
ния, влияющие на ее быстродействие и производительность. Как-то раз мы обнару- 
жили одну проблему с быстродействием в профессиональном компиляторе и про- 
следили ее источник до хэш-функции, которая всегда возвращала 0 просто потому, 
что разработчики оставили на месте тестовый, отладочный код. 

Инициализируйте массивы и переменные некоторым характерным значением, 
а не нулем. В этом случае, если вдруг произойдет выход за пределы массива или об- 
ращение к неинициализированной переменной, ошибку будет легче заметить. 
Например, константу ОхрЕАРВЕЕЕ легко заметить в среде отладчика; процедуры 
распределения памяти часто используют этот прием для обнаружения неинициали- 
зированных данных. 

Старайтесь добиться разнообразия в тестовых примерах, особенно если тесты не- 
большие и запускаются вручную. В противном случае легко попасть в наезженную 
колею, тестируя все время одно и то же, и при этом не заметить недоработок в дру- 
гом месте. 

Прекратите добавление в программу новых возможностей или даже тестирова- 
ние существующих, если в ней есть известные, обнаруженные ошибки. Пока эти 
ошибки не исправлены, они могут существенно влиять на результаты тестирования. 

Выводимые при тестировании данные должны содержать значения всех исход- 
ных параметров, чтобы тест можно было воспроизвести в точности. Если в програм- 
ме используются псевдослучайные числа, найдите способ выбрать и вывести значе- 
ние, инициализирующее их счетчик. Проследите, чтобы исходные параметры и ре- 
зультаты тестирования были представлены в достаточно четкой и ясной форме для 
их последующего понимания и воспроизведения. 

Разумно также обеспечить возможность управления количеством и типами дан- 
ных, выводимых в ходе работы программы; дополнительные данные могут помочь 
при тестировании. 

Тестируйте программу на нескольких аппаратных платформах, в нескольких вы- 
полняющих средах или операционных системах; скомпилируйте ее несколькими 
разными компиляторами. Такие сочетания позволяют обнаружить особенности, ко- 
торые не видны другими способами, например, зависимость от порядка байтов в 
слове и длины целых чисел, восприятие нулевых указателей, символов перевода 
строки и возврата каретки, специфические свойства библиотек и заголовочных фай- 
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лов. Тестирование в различных средах также позволяет обнаружить проблемы с 

объединением компонентов в единый пакет поставки и неявные или непреднаме- 

ренные зависимости от среды разработки (подробнее об этом речь пойдет в главе 8). 
Тестирование с целью анализа быстродействия рассматривается в главе 7. 


6.7. Кто занимается тестированием 


Тестирование, выполняемое самим разработчиком программы или тем, у кого 
есть доступ к исходному коду, иногда называется тестированием методом “белого 
ящика”. Название данного метода вызывает в памяти словосочетание “черный 
ящик”, про который неизвестно, что у него внутри. “Черный ящик” означает, что 
программист знает, как работать с компонентом, но не знает, как он реализован. 
Возможно, вместо “белый ящик” лучше было бы сказать “прозрачный ящик”. 

Очень важно тестировать свой код самостоятельно; не надейтесь, что это сделает за 
вас какая-нибудь организация или пользователи. Однако легко впасть в заблуждение 
по поводу того, насколько тщательно вы тестируете, поэтому постарайтесь абстрагиро- 
ваться от своего, казалось бы, досконального знания кода и думайте не о тривиальных 
случаях, а об особо сложных. Процитируем рассказ Дональда Кнута (Попа! Кпиёћ) 
о создании тестов для системы форматирования текстов ТеХ: “Я постарался вырабо- 
тать в себе самый подлый и изощренно коварный настрой, на который только был спо- 
собен, а затем написал самый гнусный (тестирующий) код, какой только смог приду- 
мать; потом я поместил его в еще более извращенные конструкции, которые находи- 
лись уже на самой грани неприличия”. Напомним, что цель тестирования — 
не продемонстрировать, что программа работает хорошо, а найти в ней ошибки. 
Поэтому тесты должны быть трудными и коварными, и если они обнаруживают про- 
блему, то следует похвалить свою методику тестирования, а не бить тревогу. 

Тестирование методом “черного ящика” означает, что тестирующий ничего 
не знает о внутреннем устройстве кода и не имеет доступа к исходному тексту. При 
таком тестировании обнаруживаются самые разные ошибки, поскольку проверке 
могут подвергнуться самые разные части кода. Начинать тестирование “черного 
ящика” лучше всего с предельных случаев, а затем переходить к более тяжелым тес- 
там: исходным данным большого объема, искаженным и неожиданным данным и, 
наконец, некорректным данным, которые программа не должна обрабатывать. 
Конечно, чтобы убедиться в правильности работы “основной линии” программы, 
следует задавать и среднестатистические, обычные исходные данные. 

На следующем этапе тестирования программа попадает в руки реального пользо- 
вателя. Новые пользователи находят новые ошибки, поскольку испытывают про- 
грамму с непредсказуемых сторон. Очень важно протестировать программу таким 
образом прежде, чем выпускать ее в широкий мир. К сожалению, многие программы 
выходят в свет без должного тестирования какого бы то ни было вида. Бета-версии 
программного обеспечения — это как раз попытка отдать программы на растерзание 
широкому кругу реальных пользователей, чтобы те попробовали их на зуб до выхода 
финальной версии. Однако выпуск бета-версий не должен подменять собой всесто- 
роннее тестирование. Впрочем, по мере того, как программные системы все больше 
усложняются и разрастаются в размерах, а график их выпуска становится все жест- 


188 Тестирование Глава 6 


че, разработчики все больше поддаются искушению уклониться от тех или иных 
этапов тестирования. 

Довольно трудно тестировать интерактивные программы, особенно если данные 
вводятся с участием мыши. Некоторые виды тестирования могут выполняться ко- 
мандными сценариями (свойства которых зависят от языка, среды и т.п.). Интерак- 
тивные программы желательно писать так, чтобы они могли управляться команд- 
ными сценариями, имитирующими ввод данных и отклик со стороны пользователя; 
в этом случае такие программы можно подвергнуть автоматическому тестированию. 
Один из способов — это записать последовательность операций пользователя, а за- 
тем воспроизвести ее автоматически; еще один подход — это встроить в программу 
язык командных сценариев, позволяющий описывать последовательность и время 
выполнения команд. 

Подумайте также и о том, что тесты сами должны подвергаться тестированию. 
В главе 5 упоминалась путаница, вызванная некорректной программой тестирова- 
ния пакета для работы со списками. Если набор регрессионных тестов “заражен” 
ошибкой, хронические проблемы гарантированы. От результатов тестирования 
немного проку, если сами тесты содержат ошибки или неточности. 


6.8. Тестирование марковской программы 


Программа генерирования текстов по марковскому алгоритму (см. главу 3) 
достаточно сложна, а поэтому требует тщательного тестирования. Она генерирует в 
целом бессмысленный текст, так что нет возможности сравнивать ее выходные дан- 
ные с каким-либо эталоном. Как читатель помнит, мы написали несколько версий на 
разных языках. Наконец, есть еще и та сложность, что программа всякий раз выдает 
случайный выходной поток, отличающийся от всех предыдущих. Как же нам приме- 
нить некоторые из уроков этой главы для тестирования такой программы? 

Первый набор тестов будет состоять из нескольких крохотных файлов и предна- 
значаться для проверки предельных случаев — корректного генерирования текста 
на основе исходных данных всего из нескольких слов. Для префиксов длиной 2 мы 
использовали пять файлов, содержащих соответственно следующие данные (по одно- 
му слову в каждой строке): 


(пустой файл) 
а 
је] 
рс 
рса 
Для каждого Из этих файлов на выходе должен получаться текст, идентичный 
исходному. Эта система тестов сразу же выявила несколько ошибок, связанных с 
просчетом на единицу при инициализации таблиц, пуске и останове генератора. 
Второй тест предназначался для проверки свойств сохранения. Для префиксов из 
двух слов должно соблюдаться то СВОЙСТВО, что любое отдельное слово, а также лю- 
бые пары и тройки слов, фигурирующие на выходе, должны содержаться также и в 
исходном файле. Мы написали программу на языке АмК, которая считывала исход- 
ный файл данных в гигантский массив, затем строила массивы всех пар и троек слов, 
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а потом считывала выходной поток марковской программы в другой массив и срав- 
нивала получившееся: 


# тест марковской программы: проверка наличия всех слов, пар и троек 
# из выходного потока АВСУ[2] во входном потоке АЮСУ [1] 
ВЕСІМ { 
мһі1е (дебііпе <АВС\У[1] > 0) 
Ғор (і = 1; 1 <= МЕ; і++) { 
ма [++пм] = $1 # слова входного потока 
ѕіпа1е[5і] ++ 


Ғор (і = 1; 1 < пм; і++) 
ра1х [ма [1] ,мӣа [1+1] ] ++ 
Ғор (і = 1; 1 < пм-1; і++) 
Єгір1е [ма [1] ‚ма [1+1] ,ма[1+2]] ++ 


мһі1е (ебі іпе <АВСУ[2] > 0) { 
оціма [++ом] = $0 # слова выходного потока 
1Е (! ($0 іп в1п91е)) 
ргіпё "опехресёеа мога", $0 


} 
Ғор (і = 1; і < ом; і++) 
ТЕ (! ((оџсма [1] ‚ очёма [1+1] іп раіг)) 
ргіпё "оипехресёеа раіг", оцёма [і], очёма [1+1] 
Ғор (і = 1; 1 < ом-1; і++) 
1Е (! ((оцёма [1], очема [1+1], очёма [1+2] ) іп ёгір1е)) 
ргіпё "опехресёеа ёгіріе", 
оцёма [1], оцема [1+1], оцёма [1+2] 


Мы даже не пытались оптимизировать этот тест, удовольствовавшись тем, чтобы 
сделать программу как можно проще. Чтобы сравнить выходной поток из 10 000 
слов со входным потоком из 42 685 слов, программе требовалось около 6-7 секунд, 
т.е. ненамного больше, чем некоторым версиям тестируемой программы понадоби- 
лось для генерирования самого текста. Проверка свойств сохранения позволила 
найти принципиальную ошибку в ]Лауа-версии: программа иногда затирала отдель- 
ные позиции в хэш-таблице, поскольку использовала ссылки вместо копирования 
префиксов. 

Данный тест иллюстрирует тот принцип, что бывает легче проанализировать 
свойства выходных данных, чем сгенерировать их. Например, легче проверить, 
отсортирован ли файл, чем отсортировать его. 

Третий тест по своей природе был статистическим. Исходные данные были такими: 


ао -езаье:. сара 


В этой последовательности на десять троек “а Ъ с” приходилась одна “а Ъ а”. 
Поэтому в выходном потоке должно было быть примерно в десять раз больше 
букв с, чем а, если программа работала с должной стохастичностью. Проверяли мы 
это, конечно, с помощью программы Ётеч. 

Статистический тест показал, что ранняя Јауа-версия программы, ассоциировав- 
шая счетчики с каждым суффиксом, выдавала по 20 букв с на каждую д, т.е. вдвое 
больше, чем необходимо. Хорошенько поломав головы, мы наконец сообразили, что 
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генератор псевдослучайных чисел в ]ауа выдает как положительные, так и отрица- 
тельные целые числа. Множитель 2 возник именно потому, что диапазон генериро- 
вания был вдвое шире, чем нужно, и нуль, деленный по модулю на счетчик, встре- 
чался вдвое чаще. В результате первый элемент списка получал предпочтение. 
Это как раз и была буква с. Чтобы исправить ошибку, необходимо было брать абсо- 
лютное значение перед делением по модулю. Без этого теста ошибка вообще не была 
бы найдена, потому что на глаз в выходном потоке было все в порядке. 

Наконец, мы “скормили” программе обычный английский текст и посмотрели, 
какую же бессмыслицу она выдаст. Разумеется, это уже проделывалось и на более ран- 
них этапах разработки программы. Но мы не успокоились, добившись того, чтобы про- 
грамма хорошо обрабатывала корректные входные данные, поскольку на практике бы- 
вает всякое. Часто возникает искушение ограничиться только качественными исход- 
ными данными, но поддаваться ему не следует; необходимо тестировать программу на 
любых, самых трудных данных. Чтобы искушение обошло вас стороной, выполняйте 
тестирование по строгой системе и в автоматизированном режиме. 

Все проделанные нами тесты были автоматизированы. Сценарий на командном 
языке генерировал нужные входные данные, запускал тесты по порядку и регистри- 
ровал все аномальные случаи. Этот сценарий был конфигурируемым, так что одни и 
те же тесты могли применяться ко всем версиям марковской программы. Всякий раз, 
когда мы вносили в одну из программ набор изменений, все тесты запускались зано- 
во для проверки правильности новой версии. 


6.9. Резюме 


Чем качественнее ваш код с самого начала его существования, тем меньше оши- 
бок в нем будет и тем крепче будет ваша уверенность в том, что проведено полное и 
всестороннее тестирование. Тестирование предельных случаев по ходу написания 
кода — это эффективный способ устранения множества мелких и глупых ошибок. 
Систематическое тестирование — это планомерное нанесение ударов по всем потен- 
циально слабым местам программы. И в этом случае ошибки чаще всего происходят 
на границах, что можно обнаружить вручную или с помощью программ. Желательно 
автоматизировать тестирование настолько, насколько это возможно, поскольку 
автоматические средства не делают случайных ляпов, не устают и не обманывают 
себя, уверяя, что код работает, если это не так. Регрессионное тестирование позволя- 
ет убедиться, что программа по-прежнему выдает правильные ответы, как она делала 
это раньше, в ее предыдущих версиях. Чтобы локализовать источники проблем, тес- 
тируйте код после каждого небольшого изменения, потому что новые ошибки, как 
правило, находятся в новом коде. 

Единственный категорический и абсолютный закон тестирования — это то, что 
его нужно делать. 
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Дополнительная литература 


Один из способов больше узнать о тестировании — это изучить примеры из луч- 
ших бесплатно распространяемых программ. В статье опа! Копи, “Те Еггог$ оѓ 
ТЕХ”, бо шате — Ргасисе апа Ехрепепсе, 1985, 19, 7, с. 607-685, описываются все 
ошибки, найденные к тому времени в системе форматирования текстов ТЕХ, а также 
рассматривается методика тестирования, применяемая автором. Прекрасным при- 
мером исчерпывающего набора тестовых примеров может служить тест ТЕР 
для системы ТЕХ. Интерпретатор Рег! также поставляется с огромным набором тес- 
товых примеров, который позволяет проверить корректность его работы после ком- 
пиляции и установки в новой системе. В этот набор входят такие модули, как Маке- 
Макег и ТезЕНагпезз, помогающие сконструировать тесты для расширений Рег]. 

Джон Бентли (оп Веп@еу) когда-то написал серию статей для журнала 
Соттитсаноп; оў АСМ, впоследствии объединенных в сборники Р’ортатття Реагі5 
и Мот Ртовтатттй Реат5. Эти сборники были опубликованы издательством 
АЧ41зоп-\ез]еу в 1986 и 1988 гг. соответственно. В этих статьях часто затрагиваются 
вопросы тестирования, особенно организации сред и оболочек для автоматизации 
обширных и всесторонних тестов. 


Быстродействие 


Он в обещаньях был могуч, как раньше, 
А висполненьях', как теперь, ничтожен. 


Вильям Шекспир. “Король Генрих МШ”? 
(\Иат 5һакеѕреағ, Ктё Непгу УП) 


Много лет назад программисты прилагали огромные усилия к тому, чтобы заста- 
вить программы работать быстрее, потому что компьютеры были медленными, 
а машинное время — дорогим. Сейчас цена упала, а скорость процессоров выросла, 
поэтому нужда в скрупулезной оптимизации быстродействия программ отпала. 
Так стоит ли вообще беспокоиться о ней? 

Да, стоит, но только если проблема действительно существует: программа рабо- 
тает слишком медленно, и есть надежда сделать ее быстрее, при этом сохранив пра- 
вильность, понятность и надежность. Быстрая программа, дающая неправильный 
ответ, вряд ли поспособствует экономии времени. 

Таким образом, первый принцип оптимизации — это, по возможности, избегать 
ее. Спросите себя: достаточно ли хорошо работает программа на данный момент? 
Зная среду и область ее применения, можете ли вы назвать преимущества, которые 
даст оптимизация ее быстродействия? Программой, написанной в виде домашнего 
задания в университете, вряд ли кто-нибудь воспользуется хотя бы несколько раз; 
поэтому ее быстродействие не имеет никакого значения. Так же обстоят дела и с 
большинством программ для личного пользования, одноразовых утилит, тестовых 
оболочек, экспериментальных программ и командных сценариев. А вот время 
выполнения коммерческого продукта или критического компонента, такого как гра- 
фическая библиотека, может оказаться очень важным, поэтому следует знать, как 
анализировать и решать проблемы быстродействия. 

В каких случаях следует оптимизировать быстродействие программы? Как это 
нужно делать? Какого результата ожидать? В этой главе рассматриваются следую- 
щие вопросы: как заставить программы работать быстрее и как использовать меньше 
памяти. Обычно быстродействие является более важным, поэтому речь пойдет в ос- 
новном именно о нем. Вопросы экономии ресурсов (оперативной памяти, дискового 
пространства) встают реже, но могут оказаться критически важными, поэтому неко- 
торое внимание мы уделим и им. 


1 Эпиграф основан на игре слов: рег/оттапсе по-английски означаст как “исполненис”, так и 
“быстродействие”. — Прим. перев. 


2 Персвод В.Томашевского. 
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Как отмечалось в главе 2, наилучшая стратегия программирования состоит в том, 
чтобы использовать самые простые и ясные алгоритмы и структуры данных из числа 
тех, что подходят для решения конкретной задачи. Затем следует измерить быстро- 
действие и решить, нужна ли его оптимизация. Включите соответствующие опции 
компилятора, чтобы получить самый быстрый код; оцените, какие изменения в 
самой программе повлияют на ее скорость сильнее всего; внесите изменения по од- 
ному за раз и снова измерьте быстродействие. При этом сохраните простейшую вер- 
сию, чтобы было с чем сравнивать оптимизированную программу. 

Необходимую часть оптимизации быстродействия составляют измерения, по- 
скольку интуиция и приблизительные прикидки — ненадежные советчики, и ими 
нельзя подменить точные методы измерения времени и профилирования программ. 
Оптимизация быстродействия имеет много общего с тестированием, включая такие 
приемы, как автоматизация, ведение регистрационных записей, регрессионное тес- 
тирование для проверки того, что новые изменения сохранили правильность работы 
программы и не вступили в конфликт с предыдущими усовершенствованиями. 

Если тщательно выбирать алгоритмы и писать в хорошем стиле с самого начала, 
то необходимость в оптимизации может и не возникнуть. В хорошо спроектирован- 
ной программе проблема быстродействия часто снимается “косметическими” 
исправлениями, тогда как в плохо написанной программе почти наверняка потребу- 
ется существенная реструктуризация. 


7.1. Узкие места 


Начнем с описания того, как мы убрали узкое место из очень важной программы, 
работающей в нашей рабочей среде. 

Наша входящая электронная почта проходит через систему, именуемую шлюзом 
(вешау) и соединяющую нашу внутреннюю сеть с внешней сетью Іпќегпеѓ. Сооб- 
щения электронной почты из внешнего мира — а это десятки тысяч в день в коллек- 
тиве из нескольких тысяч человек — сначала поступают в шлюз и только потом пе- 
редаются во внутреннюю сеть. Такое разделение позволяет изолировать нашу част- 
ную сеть от общедоступной сети Пщегпеё и представить всех членов коллектива во 
внешнем мире одним общим именем (именем шлюза). 

Одной из функций шлюза является отфильтровка “мусора”, или спама (брат), 
т.е. непрошеной почты от нежелательных адресатов, в основном содержащей сомни- 
тельную рекламу. После успешных предварительных испытаний фильтра мы уста- 
новили его в качестве постоянной функции для использования всеми пользователя- 
ми почтового шлюза. И сразу же возникла проблема. Шлюзовая система, уже уста- 
ревшая и перегруженная работой, совсем застопорилась, поскольку программа 
фильтрации работала слишком медленно, отнимая больше времени, чем все осталь- 
ные операции по обработке сообщений. В итоге почтовые очереди переполнялись, 
а доставка сообщений задерживалась на целые часы, пока система судорожно пыта- 
лась наверстать упущенное. 

Это пример самой что ни на есть откровенной проблемы с быстродействием: про- 
грамма просто-напросто неспособна выполнять свою работу достаточно быстро, и от 
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этого возникают неудобства у пользователей. Программу следовало заставить рабо- 
тать быстрее. 

Говоря несколько упрощенно, спам-фильтр функционирует следующим образом. 
Каждое входящее сообщение воспринимается как одна строка, и модуль поиска тек- 
стовых соответствий проверяет, не содержит ли эта строка фраз из известных спам- 
сообщений, например, "Маке ті11іопз іп уоџг ѕраге біте" ("Заработайте 
миллионы в свободное время") или "ХХХ-үабеа" ("порнография"). 
Спам-сообщения имеют тенденцию повторяться, так что этот подход вполне практи- 
чен; если спам-сообщение не перехватывается один раз, ключевая фраза из него добав- 
ляется в список, чтобы в следующий раз оно не прошло. 

Ни одна из утилит текстового поиска и сравнения, таких как агер, не обладает 
должным сочетанием таких качеств, как быстродействие и удобство настройки. 
Поэтому мы написали специальный спам-фильтр. Первоначальный код был очень 
прост: в нем каждое сообщение проверялось на наличие любой из фраз заданного 
списка (образцов). 


/* іѕѕрат: содержит ли меза любой элемент раё */ 
1106 іѕѕрат(сһаг *теѕ9) 


{ 


106 і; 
Ғог (1 = 0; і < пра; 1++) 
1Е (зе хзег(теза, ра [1]) != Моц) { 
ргіпё# ("зраш: паісһ Ёог `%5'\п", раї [1]); 
гесигп 1; 
} 
гесигп 0; 


} 


Как же сделать эту программу быстрее? Здесь необходимо выполнять поиск в 
строке, и для этой цели лучше всего подходит библиотечная функция зе хех языка 
С, стандартная и быстродействующая. 

С помощью профилирования — техники, о которой будет сказано подробнее в 
следующем разделе, — мы выяснили, что реализация функции зЕхзЕг неудачна для 
ее использования в спам-фильтре. Изменяя алгоритм ее работы, ее можно было сде- 
лать более эффективной для данной конкретной задачи. 

Стандартная реализация 5Егз Ех выглядела примерно следующим образом: 


/* простейшая зЕх5Етг: поиск первого символа с помощью 5зехусйг */ 
сһаг *ѕігѕіг (сопѕ сһаг *51, сопѕі сһаг *52) 


{ 


116 п; 
п = ѕіг1еп (52); 
гот (Я) { 


51 = зірсһү (51, 52[0]); 
1Е (51 == М) 
геигүп МО; 
1Е (зе хпстр (51, 52, п) == 0) 
гесигүп (сһаг *) 51; 
51++; 
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Эту функцию писали, ориентируясь на максимальное быстродействие, и, дейст- 
вительно, в большинстве типичных приложений она работала очень быстро, потому 
что всю работу в ней выполняли оптимизированные библиотечные средства. Для 
поиска первого символа строки она вызывает функцию зегсһү, а затем с помощью 
функции зегпстр выясняет, соответствует ли продолжение строки заданному об- 
разцу. Итак, функция сразу отсеивает большую часть сообщения, разыскивая только 
первый символ, а затем быстро проверяет остальное. Почему же этот алгоритм рабо- 
тает недостаточно быстро? 

Для этого есть несколько причин и, соответственно, несколько путей совершен- 
ствования программы. Во-первых, функция зЕхпстр принимает в качестве аргу- 
мента длину образца поиска, которая вычисляется функцией зе х1еп. Но образцы 
известны заранее, поэтому их длину не обязательно пересчитывать для каждого 
сообщения. 

Во-вторых, функция зЕхистр имеет сложный внутренний цикл. Она должна не 
только сравнивать две строки байт за байтом, но еще и проверять завершающий байт 
(\0) в обеих строках, попутно продолжая отсчитывать параметр длины в сторону 
уменьшения. Поскольку длины всех строк известны заранее (хотя функция зЕхстр 
об этом не знает), такое усложнение алгоритма не обязательно; мы и так знаем, что 
счет ведется правильно, так что проверка нулевого байта просто излишня. 

В-третьих, функция ѕсгсһг также устроена сложно, поскольку она одновремен- 
но разыскивает символ и следит, чтобы не встретился конец строки в виде нулевого 
байта (\0). При каждом конкретном вызове функции іѕѕрат сообщение имеет 
фиксированную длину и содержание, поэтому контроль нулевого байта — пустая 
потеря времени; мы и так знаем, где заканчивается сообщение. 

Наконец, хотя функции ѕзегпстр, збгсһг и зех1еп вполне экономичны сами по 
себе (в изоляции друг от друга), но расход времени на их вызов сравним с продол- 
жительностью тех операций, которые они выполняют. Было бы эффективнее вы- 
полнить всю работу в специальной, тщательно оптимизированной функции типа 
зЕхзЕх, вообще избежав вызова остальных. 

Такого рода проблема — типичный источник неприятностей с быстродействием. 
Какая-нибудь подпрограмма или интерфейс работает вполне хорошо во всех типич- 
ных случаях, однако дает сбои в случаях нетипичных, и к тому же таких, когда дан- 
ный компонент является центральным для программы. Стандартная функция 
зЕхзех работала отлично для коротких строк и образцов поиска, изменяющихся 
при каждом вызове, но при длинных фиксированных строках лишний необоснован- 
ный расход времени стал уже критическим. 

Имея все это в виду, мы переписали функцию зе гзех так, чтобы она выполняла 
перебор как строки сообщения, так и строки образца поиска одновременно и без вызо- 
ва каких-либо подпрограмм. Получившаяся реализация обладала предсказуемыми 
свойствами: она работала несколько медленнее в отдельных случаях, но в целом 
справлялась с фильтрацией спам-сообщений намного быстрее и, что очень важно, ни- 
когда не замедлялась до недопустимо низкой скорости. Для контроля правильности и 
быстродействия новой версии был разработан набор тестовых данных. Он включал в 
себя нетолько простые примеры наподобие поиска слова или предложения, но также и 
совершенно патологические случаи наподобие поиска одной буквы х в строке из тыся- 
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чи букв е или поиска строки из тысячи х в строке из одной буквы е. Такие задания 
неизменно вызывали затруднения у стандартной реализации. Подобные экстремаль- 
ные случаи являются ключевой частью оценки быстродействия. 

Итак, в библиотеку была добавлена новая функция зЕх зе, и спам-фильтр зара- 
ботал примерно на 30% быстрее, что можно считать весьма неплохим результатом 
исправления всего одной функции. 

К сожалению, такой скорости по-прежнему было недостаточно. 

При решении задач и проблем важно задавать правильные вопросы. До сих пор 
мы спрашивали, как быстрее всего найти образец текста в строке. Но фактическая 
задача состоит в том, чтобы разыскать вхождения строк из большого, заранее 
известного набора в длинной строке переменной длины и содержания. При такой 
постановке задачи функция зЕхзех уже не кажется оптимальным решением. 

Самый эффективный способ ускорить работу программы — это выбрать для нее 
более оптимальный алгоритм. Имея четкое представление о задаче, следует поду- 
мать, какой же алгоритм лучше всего подходит для ее решения. 

Основной цикл выглядит так: 

Ғог (і = 0; 1 < праЕ; 1++) 
1Е (зе хзех(теза, раб [1]) != МО) 
гебцуп 1; 


В нем выполняется прас независимых переборов сообщения; если предполо- 
жить, что не найдено ни одного соответствия, то каждый байт сообщения перебира- 
ется пра раз, что дает зЕх1еп (теза) *прае операций сравнения. 

Лучший способ — это обратить циклы и перебирать сообщение один раз во внеш- 
нем цикле, параллельно разыскивая в нем все заданные образцы во внутреннем цикле: 


Бог (ј = 0; теѕа[ј] != '\0'; ј++) 
1Е (ѕоте раекехгп таёсһеѕ ѕбагёіпд а мезча [ј]) 
геёигп 1; 


Очередное усовершенствование быстродействия основано на одном простом 
наблюдении. Чтобы проверить, не совпадает ли текст, начинающийся в позиции ј, 
с каким-либо из образцов, совсем не обязательно перебирать их все — достаточно про- 
верить те, которые начинаются с того же символа, что и теза [3]. Приблизительно 
можно считать, что будет выполняться около ѕёг1еп (теѕа) *праё /52 сравнений 
(поскольку проверяется 26 больших и столько же маленьких букв, в сумме 52). 
Но частоты употребления букв английского алфавита не одинаковы — слова, начи- 
нающиеся с з, встречаются гораздо чаще, чем начинающиеся с х. Поэтому улучше- 
ния быстродействия в 52 раза ожидать не приходится, и все же что-то мы выиграем. 
Фактически мы строим хэш-таблицу, ключом которой является первый символ 
заданного образца. 

Даже после добавления предварительных операций по построению таблицы 
образцов функция ізѕзрат остается достаточно короткой: 


іп рас1еп [МРАТ); /* длина образца */ 
іпе ѕбагсіпа [ОСНАК_МАХ+1] [М5ТАКТ]; /* образцы, нач. с символа */ 
106 пѕбагёіпа [ОСНАВ_МАХ+1]; /* количество образцов */ 


/* іѕѕрат: ищет, встречается ли в теѕд любой из образцов */ 
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106 іѕѕрат(сһаг *теза) 


{ 
ЕК 
чпѕічпеа сһаг с; 
Ғор (ј = 0; (с = теѕа[5]) != '\0'; ј++) { 
Ғор (і = 0; 1 < пѕзбагііпа [с]; і++) { 
К = ѕбагііпа [с] [1]; 
1Е (тетстр (теѕ+ј, раб [к], раё1еп[к]) == 0) { 
ргіпе# ("ѕрат: таёсһ Ғог `%5'\п", раї [к]); 
гесогп 1; 
} 
} 
} 
геіцгп 0; 


Двумерный массив зкахЕ1па [с] [] содержит для каждого символа с индексы 
тех образцов, которые начинаются с данного символа. В паре с ним используется 
массив пебагііпа [с], в котором запоминается, сколько образцов начинается с 
каждого из символов с. Без этих таблиц внутренний цикл выполнялся бы от.0 до 
прае, т.е. порядка тысячи раз; вместо этого он выполняется от 0 до примерно 20. 
Наконец, элемент массива рас1еп [к] содержит вычисленный заранее результат 
операции ѕёг1еп (раї [К] ). 

На следующем рисунке изображены описанные структуры данных для набора из 
трех образцов, начинающихся с буквы Ъ. 


пзбагііпдо: ѕіагііпд: 


[67 1117 [3597 


рід рискѕ 


реѕі рісёигеѕ! 


Код для построения этих таблиц выглядит несложно: 
116 і; 
чпѕідпеа сһаг с; 


Ғор (і = 0; і < праб; 1++) { 
с = раї [1] [0]; 
1ЁЕ (пѕбагбіпд [с] >= МУТАВТ) 
ерх1пЕЁ ("Соо тапу расёегпѕ (>=%а) Бредіп !'%с'", 
МЅТАРТ, с); 
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сах 1па [с] [пѕбагсіпа [с] ++] = і; 
раё1еп [і] = ѕіг1еп (раї [1]); 


В зависимости от состава исходных данных спам-фильтр теперь работает при- 
мерно в пять-десять раз быстрее, чем раньше, когда в нем использовалась усовер- 
шенствованная функция ѕбгзег, и от семи до пятнадцати раз быстрее, чем работала 
его исходная версия. Улучшения в 52 раза достичь не получилось — частично из-за 
неравномерного распределения букв по частоте употребления, частично из-за боль- 
шей сложности цикла в новой программе, а частично еще и потому, что по-прежнему 
приходится выполнять много безрезультатных сравнений строк. Однако спам- 
фильтр перестал быть узким местом в системе доставки почты. Проблема быстро- 
действия решена. 

В остальной части этой главы будут обсуждаться методы обнаружения проблем с 
быстродействием, вычленения слишком медленного кода и ускорения его работы. 
Но прежде чем двигаться дальше, стоит еще раз посмотреть на спам-фильтр и подвести 
итоги, чему же он нас научил. Итак, прежде всего следует убедиться, что проблема 
действительно заключается в недостаточном быстродействии программы. Все наши 
усилия пропали бы даром, если бы узким местом системы был не спам-фильтр. Зная, 
что проблема быстродействия существует, следует воспользоваться техникой профи- 
лирования и другими аналогичными методами для изучения поведения программы и 
локализации конкретного места проявления проблемы. Затем следует убедиться в дос- 
таточной общности своего подхода к проблеме; так, мы анализировали всю программу, 
а не одну только функцию зЕгзех, которая первой бросалась в глаза, но отнюдь не 
являлась основной виновницей. Наконец, мы решили именно ту проблему, которую 
было нужно, используя более совершенный алгоритм, и убедились, что программа 
действительно работает быстрее. Как только нужное быстродействие было достигнуто, 
мы остановились — в конце концов, зачем же перенапрягаться? 

Упражнение 7.1. Таблица, в которой одному символу ставится в соответствие 
набор текстовых образцов, начинающихся с этого символа, дает скачок быстродей- 
ствия величиною в порядок. Напишите версию функции 1ззраш, которая бы ис- 
пользовала в качестве индекса два символа. Какого улучшения быстродействия уда- 
ется достигнуть в этом случае? Это простые частные случаи структуры данных под 
названием “ТЕІЕ-структура” или “бор”, являющейся обобщением дерева поиска. 
Большинство таких структур данных построено на том или ином компромиссе меж- 
ду объемом и быстродействием. 


7.2. Измерение времени и профилирование 


Автоматизируйте измерение времени при разработке программ. В большин- 
стве систем имеются команды для измерения времени, затрачиваемого на выполне- 
ние программы. В Ошх эта команда называется біте: 


% сіте з1омркочгам 
геа1 7.0 

ц5ег 6.2 

ѕуѕ 0.1 


5 
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После выполнения команды на экране появляются три числа, показывающие 
время в секундах. Первое число — это “реальное” время, в течение которого работала 
программа; второе — это “пользовательское” время, затраченное процессором на вы- 
полнение программы; третье — это “системное” время, затраченное операционной 
системой на программу. Если в вашей системе есть аналогичная команда, пользуй- 
тесь ей. В любом случае выдаваемые ею данные будут более информативными, на- 
дежными и простыми в получении, чем при измерении времени вручную секундо- 
мером. Также не забывайте вести регистрационные записи. При работе над про- 
граммой, внесении модификаций и выполнении измерений накапливается большой 
объем данных, которые в один прекрасный день собьют вас с толку. (Какая из двух 
десятков версий работала на 20% быстрее остальных?) Многие из методов, рассмат- 
риваемых в главе о тестировании, можно адаптировать к целям измерения времени и 
повышения быстродействия. Автоматизируйте выполнение и замеры времени вы- 
полнения тестовых примеров и, что еще важнее, не забывайте о регрессионном тес- 
тировании, гарантирующем, что вносимые изменения не нарушают правильности 
работы программы. 

Если в системе нет команды замера времени или же необходимо измерить вы- 
полнение отдельной функции, то можно написать программу-оболочку (аналогич- 
ную оболочке тестирования) для такого замера самостоятельно. В языках С и С++ 
имеется стандартная функция с1оск, сообщающая, сколько процессорного времени 
программа затратила к моменту ее вызова. Чтобы измерить длительность выполне- 
ния какой-нибудь функции, можно вызвать с1оск перед ней и после нее: 


#1пс1аае <ёіте.Һ> 
#1пс1аае <ѕіаіо.Һ> 


Сс1оск_Е БеЁоге; 

Яоцр1е е1арѕеа; 

реҒоге = с1оск(); 

1оп9 гиппіпя Ғцпсііоп(); 

е1арѕеа = с1оск() - реЁоге; 

ргіпЕ# ("Ёцпсёіоп ичзеа %.3# зесопаз\п", 
е1арѕеа/с1оскѕ РЕВ ЅЕС); 


Масштабный множитель СІОСКЅ РЕВ ЅЕС характеризует разрешающую спо- 
собность таймера, сообщаемую функцией с1оск. Если выполнение функции отни- 
мает всего лишь долю секунды, включите ее в цикл, но не забудьте учесть дополни- 
тельные затраты времени на организацию цикла, если это имеет значение: 

реЁоге с1оск (); 
Бог (і = 0; 1 < 1000; і++) 
ѕћҺог гиппіпо Ёцпсёіоп(); 
е1арѕеа = (с1оск () -БеЁоге) / (доџр1е) і; 


В языке Јауа имеется класс Расе с функциями, выдающими обычное время, 
которое является приближением к времени процессора: 


Расе реЁоге = пем раёе (); 
1оп9 гиппіпо Ёцпсёіоп(); 
Расе а#бег = пем рае (); 
1опа е1арѕеа = а#ёсег.деёТіте () - реҒоге.деіТіте (); 
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Функция десТіте возвращает время в миллисекундах. 


Пользуйтесь программами профилирования. Кроме надежного метода измере- 
ния времени, наиболее важным инструментом анализа быстродействия является 
программа или система профилирования. Профиль — это подробный отчет о том, на 
что именно программа тратит свое время выполнения. Некоторые профили состоят 
из списка функций с указанием количества вызовов каждой и доли общего времени 
программы, которая затрачена на выполнение этой функции. В других перечисляет- 
ся, сколько раз выполняется тот или иной оператор. Часто выполняемые операторы 
отвечают за болыпую часть общего времени, в то время как никогда не выполняемые 
могут указывать на бесполезный или должным образом не протестированный код. 

Профилирование — это эффективное средство поиска горячих точек программы, 
т.е. функций или фрагментов кода, отнимающих большую часть времени выполне- 
ния. Впрочем, и результаты профилирования следует воспринимать критически. 
Учитывая сложность компиляции и побочных эффектов управления памятью (в том 
числе кэширования), а также тот факт, что профилирование также влияет на быст- 
родействие программы, статистика в профиле дает лишь приблизительную картину. 

В статье, вышедшей в 1971 году, Дональд Кнут (Оопа!4 Кпиёћ), автор самого тер- 
мина “профилирование”, писал следующее: “..менее 4 процентов общего объема про- 
граммы отнимают более половины времени на ее выполнение”. Отсюда следует способ 
применения профилирования. Вначале необходимо обнаружить критические места 
программы, выполнение которых отнимает больше всего времени, затем оптимизиро- 
вать их в максимально возможной степени и снова произвести замеры, чтобы прове- 
рить, не появится ли на поверхности новая горячая точка. Обычно после одной-двух 
итераций этого процесса в программе не остается бросающихся в глаза горячих точек. 

Профилирование обычно включают специальным ключом или опцией компиля- 
тора. Программа выполняется почти как обычно, а затем модуль анализа выдает 
результаты. В системе Цшх этот ключ обычно имеет вид -р, а программа профили- 
рования называется ргоѓ: 


% сс -р ѕрапёсеѕё.с -о ѕрапёеѕі 
% ѕратсезі 
% ркоЕ ѕрапіеѕі 


В следующей таблице представлен профиль, сгенерированный для специальной 
версии спам-фильтра. Мы написали ее специально для лучшего понимания работы 
программы. В ней используются фиксированное почтовое сообщение и фиксиро- 
ванный набор из 217 фраз, разыскиваемый в сообщении 10 000 раз. Эта программа 
выполнялась на машине М[Р5 К10000 с тактовой частотой 250 МГц. В ней исполь- 
зуется исходная версия алгоритма с функцией зехзЕх, вызывающей другие стан- 
дартные функции. Результат переформатирован с тем, чтобы помещаться на стра- 
ницу. Обратите внимание, что объем входных данных (217 фраз) и количество опе- 
раций поиска (10 000) фигурируют в столбце подсчета количества вызовов “са|]5”, 
осуществляя тем самым косвенную проверку соответствия алгоритма и программы. 


12234768552: Тоба] питрег оЁ іпѕёгисёіопѕ ехесибеа 
13961810001: ТоЕа1 сотриёеа сус1ез 
55.847: Тоба1 сотрибеа ехесисіоп Е1ме (зесз.) 
1.141: Ауегаде сус1еѕ / 1п5ЕхисЕ1оп 
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ѕесѕ $ сит сус1ез іпѕёгоссіопѕ са118 Ғопсбіоп 


45.260 81.0% 81.0% 11314990000 9440110000 48350000 ѕёгсһг 


6.081 10.9% 91.9% 1520280000 1566460000 46180000 ѕегпстр 
2.592 4.6% 96.6% 648080000 854500000 2170000 зЕузех 
1.825 3.3% 99.8% 456225559 344882213 2170435 з6г1еп 
0.088 0.2% 100.0% 21950000 28510000 10000 іѕѕрат 
0.000 0.0% 100.0% 100025 100028 1: таіп 
0.000 0.0% 100.0% 53677 70268 219 _метссру 
0.000 0.0% 100.0% 48888 46403 217 зегсру 
0.000 0.0% 100.0% 17989 19894 219 Едеёз 
0.000 0.0% 100.0% 16798 17547 230 _ ма11ос 
0.000 0.0% 100.0% 10305 10900 204 геа1Егее 
0.000 0.0% 100.0% 6293 7161 217 еѕегаийр 
0.000 0.0% 100.0% 6032 8575 231 с1еап гее 
0.000 0.0% 100.0% 5932 5729 1 геаарас 
0.000 0.0% 100.0% 5899 6339 219 дес1іпе 
0.000 0.0% 100.0% 5500 5720 220 _та11ос 


Бросается в глаза, что функции ѕєгсһг и ѕеєгпстр, вызываемые из функции 
зегзех, полностью доминируют в программе по времени выполнения. Итак, мнение 
Д. Кнута вполне обосновано: выполнение небольшой части программы занимает 
большую часть общего времени выполнения всей программы. При первом профили- 
ровании программы вполне можно обнаружить функцию, которая отнимает более 
50% всего времени выполнения, как это и происходит в нашем случае. Здесь легко 
решить, на чем сосредоточить внимание при оптимизации программы. 


Концентрируйтесь на горячих точках. Переписав зе хз, мы снова перепро- 
филировали программу зратёезе и обнаружили, что теперь 99,8% всего времени 
затрачивается на выполнение функции зехгзех, даже при том, что программа в 
целом стала работать значительно быстрее. В тех случаях, когда одна-единственная 
функция является настолько узким местом, есть только два пути: усовершенст- 
вовать функцию, применив другой алгоритм, или избавиться от нее вообще, изменив 
структуру всей программы. 

В данном случае мы переписали всю программу. Ниже приведены первые 
несколько строк профиля программы зратеезе с использованием окончательной, 
быстрой версии функции іѕѕрат. Обратите внимание, что общее время выполнения 
значительно уменьшилось, горячей точкой стала функция тетстр, а і ѕѕрат теперь 
потребляет существенную часть ресурсов процессорного времени. Последняя стала 
значительно сложнее, чем та версия, из которой вызывалась функция зехзех, но 
стоимость этого более чем компенсируется устранением вызовов ѕёг1еп и зе гсНх, 
а также заменой зехпстр на мешстр, которая выполняет в среднем меньше опера- 
ций на один байт. 


зесз $ Сом сус1ез іпѕёгиссіопѕ са118 Ғопсбіоп 
3.524 56.9% 56.9% 880890000 1027590000 46180000 тетстр 
2.662 43.0% 100.0% 665550000 902920000 10000 1ззрам 
0.001 0.0% 100.03 140304 106043 652 зЕг1еп 


0.000 0.0% 100.03 100025 100028 1 таіп 
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Поучительно сравнить количество выполнений циклов и вызовов функций в 
двух приведенных профилях. Заметьте, что ѕсг1еп теперь вызывается не несколько 
миллионов раз, а всего 652, причем количество вызовов ѕсгпстр и метстр совпада- 
ет. Отметим также, что 15зрам, теперь выполняющая еще и работу функции 
ѕсгсһү, все же укладывается в намного меньшее количество циклов, чем это делала 
ѕсгсһү, поскольку на каждом шаге проверяет только образцы, которые реально мо- 
гут встретиться в тексте. Изучение приведенных чисел может рассказать еще много 
интересного об особенностях выполнения программы ранее и теперь. 

Горячую точку часто можно устранить или хотя бы “охладить” гораздо менее 
изощренным перепроектированием программы, чем то, к которому мы прибегли в 
спам-фильтре. Довольно давно профилирование А\К показало, что в ходе регресси- 
онного тестирования одна из функций вызывалась около миллиона раз в следующем 
цикле: 


? Бог (ј = 1; ј < МАХЕШО; ј++) 
? с1еах (7); 


Цикл, в котором очищаются поля перед считыванием следующей строки входных 
данных, отнимал ни много ни мало 50% всего времени выполнения программы. Кон- 
станта МАХЕІР, обозначающая максимально допустимое количество полей в строке 
данных, была равна 200. Но в большинстве приложений А\К фактическое количест- 
во полей не превышало 2 или 3. Таким образом, огромное количество времени тра- 
тилось на очистку полей, в которые и так никогда не помещались никакие значения. 
Замена этой константы ее предыдущим значением дала ускорение примерно на 25%. 
Чтобы добиться этого повышения быстродействия, понадобилось всего-то заменить 
верхний предел количества полей: 

Ғор (ј = і; ј < махЕ1Я; ј++) 
с1еаү(ј); 
тах Ғ 1а = і; 


Чертите графики. При измерении быстродействия особо полезны различные 
графики и схемы, иллюстрирующие результаты таких измерений. По ним можно 
проследить влияние изменения тех или иных параметров, сравнить алгоритмы и 
структуры данных, а иногда и выявить случаи неожиданного поведения. Так, графи- 
ки длин цепочек, построенные для ряда хэш-коэффициентов (см. главу 5), отчетливо 
продемонстрировали, что некоторые коэффициенты были лучше для использования 
в хэш-таблице, чем другие. 

На следующем графике показано, как размер массива хэш-таблицы влияет на 
время выполнения С-версии программы тагкоу с Книгой Псалмов в качестве 
исходных данных (42 685 слов, 22 482 префиксов). Мы провели два эксперимента. 
В одной серии использовались размеры массивов, равные степеням двойки от 2 до 
16384. В другом размеры массивов были равны наиболыпим простым числам, 
меньшим соответствующей ближайшей степени двойки. Нам хотелось посмотреть, 
влияет ли сколько-нибудь заметным образом на быстродействие программы приме- 
нение массива с длиной, равной простому числу. 
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50 х Степени двойки 


20 ® Простые числа 


10 
Время выполнения 5 


(с) 


1 10 100 1000 10000 


Размер хэш-таблицы 


На графике видно, что время выполнения программы с такими входными дан- 
ными не чувствительно к размеру таблицы, если он превышает 1000 элементов; 
ктому же никакой заметной разницы между применением степеней двойки и про- 
стых чисел не выявлено. 


Упражнение 7.2. Вне зависимости от того, есть ли в вашей системе команда 
Е 1те, или нет, напишите утилиту измерения времени самостоятельно с применени- 
ем функции с1осК или дееТ1те. Сравните выдаваемые ею результаты с замером 
времени по секундомеру. Как влияют на измерение времени системные операции? 


Упражнение 7.3. В первом из приведенных выше профилей функция ѕёгсһг 
вызывалась 48 350 000 раз, тогда как зегпстшр — только 46 180 000. Объясните эту 
разницу. 


7.3. Стратегия ускорения 


Прежде чем оптимизировать быстродействие программы, убедитесь, что она дей- 
ствительно работает недостаточно быстро. Чтобы выяснить, на что же тратится вре- 
мя, воспользуйтесь утилитами измерения времени и профилирования. Зная, что в 
действительности происходит, прибегните к одной из известных стратегий оптими- 
зации. Некоторые из них описаны ниже в порядке убывания важности. 


Выберите лучший алгоритм или структуру данных. Наиболее важным факто- 
ром, влияющим на быстродействие программы, является выбор алгоритмов и структур 
данных. Между эффективными и неэффективными алгоритмами бывает огромная 
разница. В нашем спам-фильтре замена структуры данных привела к ускорению в 
десять раз; возможна и еще большая оптимизация, если новый алгоритм уменьшает 
порядковую оценку количества операций, например, с О(и’) на О(п Іов п). Эта тема 
рассматривалась в главе 2, так что здесь на ней останавливаться не будем. 

У достоверьтесь, что сложность алгоритма действительно имеет под собой осно- 
вания; в противном случае за этой сложностью может скрываться дефект быстро- 
действия. Например, следующий алгоритм перебора строки на первый взгляд 
кажется линейным: 
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? Ғор (і = 0; і < зЕх1еп(3); 1++) 
1Е (3[1] == с) 


о 


Но на самом деле он имеет квадратичный порядок: если в строке п символов, то 
при каждом вызове функции зєг1еп перебираются все эти п символов и при этом 
весь цикл также выполняется п раз. 


Включите оптимизирующую компиляцию. Одна из модификаций, которая 
не требует никаких усилий, но может дать существенное улучшение быстродейст- 
вия, — это включить все опции оптимизации, которые предлагает компилятор. 
Современные компиляторы позволяют программисту практически обойтись без вы- 
полнения большинства локальных оптимизаций вручную, поскольку достаточно 
хорошо делают это автоматически. 

По умолчанию компиляторы С и С++ не выполняют почти никакой оптимиза- 
ции. Одна из опций компилятора активизирует оптимизатор (хотя более точным 
термином был бы “реорганизатор”). Возможно, стоило бы сделать его включаемым 
по умолчанию, кроме тех случаев, когда оптимизация вносит путаницу в отладку 
исходного кода. Поэтому программистам следует включать оптимизацию тогда, ко- 
гда они полагают, что отладка закончена. 

Оптимизирующая компиляция повышает быстродействие по-разному: от не- 
скольких процентов до двух раз. Однако бывает и так, что программа от подобной 
оптимизации только замедляется, поэтому следует тщательно измерить степень 
улучшения до предоставления программы пользователю. Мы сравнили оптимизи- 
рованный и неоптимизированный код на примере одной-двух версий спам-фильтра. 
Для тестового примера с применением окончательной версии алгоритма поиска и 
сравнения исходное время выполнения составляло 8,1 секунды, а при включенной 
оптимизации — 5,9 секунды, что составило улучшение почти на 25%. С другой сто- 
роны, версия со стандартной функцией зегзех вообще не поддалась оптимизации, 
потому что эта функция уже была оптимизирована при ее помещении в библиотеку. 
Оптимизация применяется только к коду, компилируемому в данный момент, но не 
к тому, который берется из системных библиотек. Однако в некоторых компилято- 
рах все-таки есть глобальные оптимизаторы, анализирующие всю программу на 
возможность потенциального улучшения быстродействия. Если такой компилятор 
имеется в вашей системе, испытайте его; он может помочь вам сократить работу по 
оптимизации кода. 

Следует иметь в виду одно обстоятельство: чем интенсивнее компилятор выпол- 
няет оптимизацию, тем более вероятно, что он может внести ошибку в скомпилиро- 
ванную программу. Поэтому после включения оптимизации следует еще раз выпол- 
нить регрессионное тестирование, как и в случае любых других модификаций. 


Выполняйте тонкую настройку кода. Если объем обрабатываемых данных 
очень велик, большое значение имеет правильный выбор алгоритма. Более того, 
алгоритмические усовершенствования сохраняются при переходе в другие системы, 
к другим компиляторам и языкам. Но если уже выбран наилучший возможный ал- 
горитм, а проблема быстродействия остается, то следующее, что следует попробо- 
вать, — это выполнить тонкую настройку кода, т.е. попытаться изменить организа- 
цию циклов и выражений так, чтобы они выполнялись как можно быстрее. 
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Та версия 1 ззрат, которую мы продемонстрировали в конце раздела 7.1, не под- 
вергалась такой настройке. Здесь же будет показано, как можно достичь дальнейше- 
го улучшения, реорганизовав цикл. Напомним, как он выглядел первоначально: 

Еог (ј = 0; (с = теѕ9 [3]) != '\0'; ј++) { 
Еог (і = 0; і < пзёагбіпа [с]; 1++) { 
К = ѕбагбіпд [с] [1]; 


1Е (тетспр (теѕд+ј, раё [к], раЕ1еп[К]) == 0) { 
рке1пЕЕ ("ѕрат: таёсһ Ёог '%5'\п", рас [К]); 
геёиүп 1; 


} 


Эта начальная версия, скомпилированная с включенной оптимизацией, выполня- 
ется за 6,6 секунды на нашем тестовом примере. В условии внутреннего цикла фигу- 
рирует индекс массива (песагііпо [с]), значение которого фиксировано на про- 
тяжении одного прохода внешнего цикла. Поэтому его пересчета можно избежать, 
сохранив это значение в локальной переменной: 

Еох (ј = 0; (с = теѕ9 [3]) != '\0'; ј++) { 
п = пѕбагбіпд [с]; 
Бог (і = 0; і < п; і++) { 
К = ѕбагбіпа [с] [1]; 


В результате время выполнения падает до 5,9 секунды, что примерно на 10% 
быстрее. Именно такая степень оптимизации обычно достигается тонкой настрой- 
кой. Имеется еще одна переменная, использование которой можно реорганизо- 
вать, — элемент ѕсагсіпа [с] также фиксирован. На первый взгляд, вынесение его 
вычисления за пределы цикла может еще ускорить процесс, но в нашем тесте ника- 
кой заметной разницы обнаружено не было. Это также характерно для тонкой 
настройки: что-то поддается оптимизации, что-то — нет, и следует проводить точные 
измерения, чтобы обнаружить эту разницу. Кроме того, результаты такой настройки 
могут отличаться на различных платформах и с различными компиляторами. 

В спам-фильтр можно внести и еще одно усовершенствование. Во внутреннем 
цикле проверяется наличие в строке целого заданного образца текста, но сам алго- 
ритм уже гарантирует совпадение первых символов. Поэтому мы попытались вы- 
полнить тонкую настройку, начиная сравнение в функции тетстр на один байт 
дальше. Настройка дала ускорение около 3%, что хотя и немного, но зато потребова- 
ло изменения всего трех строк кода, одна из которых выполняет предварительные 
вычисления. 


Не оптимизируйте то, что не имеет значения. Иногда тонкая настройка 
не дает никакого результата, потому что применяется там, где оптимизировать нече- 
го. Убедитесь, что ваша оптимизация действительно применяется к коду, выполне- 
ние которого отнимает много времени. Следующая история не вполне достоверна, 
но мы ее все же расскажем. Одну из систем ныне несуществующей компании анали- 
зировали с помощью аппаратного измерителя быстродействия и обнаружили, что 
около 50% всего времени она выполняет одну и ту же последовательность несколь- 
ких инструкций. Инженеры встроили в систему специальную инструкцию, объеди- 
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няющую в себе функции той последовательности, перезапустили новую систему и 
обнаружили, что никакой разницы с предыдущей нет. В итоге оказалось, что они 
оптимизировали холостой цикл операционной системы! 

Как много времени и усилий позволительно тратить на оптимизацию быстродейст- 
вия программы? Основной критерий состоит в том, чтобы вносимые изменения оку- 
пились в будущем. Ориентировочно можно сказать так: рабочее время, потраченное на 
настройку быстродействия, не должно быть больше, чем время, впоследствии сэко- 
номленное этой настройкой за срок существования программы. В соответствии с этим 
правилом алгоритмическое усовершенствование программы 15зрам стоило свеч: оно 
заняло один рабочий день, а сэкономило (и продолжает экономить) несколько часов 
каждый день. Устранение индексации массива во внутреннем цикле менее заметно, 
однако и его стоило проделать, поскольку программа в течение длительного времени 
обслуживает большой коллектив пользователей. Оптимизация общественно полезных 
программ наподобие спам-фильтра или библиотек окупается почти всегда, тогда как 
оптимизация тестовых одноразовых программ — почти никогда. Если программа 
должна проработать как минимум год, оптимизируйте в ней все, что только можете. 
Оптимизацию стоит выполнить, даже если программа уже работает месяц, но вы обна- 
ружили способ ускорить ее работу еще на 10%. 

Коммерческие и другие общедоступные программы, испытывающие конкуренцию 
со стороны своих аналогов, такие как игры компиляторы, электронные таблицы, 
системы управления базами данных, тоже попадают в эту категорию, поскольку успе- 
хом у пользователя чаще всего пользуются наиболее быстрые и эффективные из них. 
По крайней мере, так отмечается в опубликованных сравнительных характеристиках. 

Важно измерять время выполнения программ по мере внесения изменений, что- 
бы убедиться, что программа постепенно совершенствуется. Иногда два изменения, 
которые сами по себе улучшают работу программы, накладываясь, нейтрализуют 
эффект друг друга. В этом случае измерение времени может давать настолько не- 
ожиданные результаты, что становится трудно делать какие-то заключения о влия- 
нии вносимых изменений на быстродействие. 

Даже в однопользовательских системах время выполнения подвержено непредска- 
зуемым флуктуациям. Если разброс измерений внутреннего таймера (или, по крайней 
мере, тех значений, которые сообщает система) составляет 10%, то изменения, дающие 
оптимизацию в пределах этих же 10%, трудно отличить от фонового шума. 


7.4. Настройка кода 


Существует много способов снизить затраты времени, если в программе обнаруже- 
на горячая точка. В этом разделе приведены некоторые рекомендации, которыми сле- 
дует пользоваться аккуратно, неизменно выполняя регрессионное тестирование после 
каждой модификации, чтобы убедиться, что код по-прежнему работает правильно. 
Имейте в виду, что хорошие компиляторы выполняют некоторые из этих оптимизаций 
самостоятельно, и нередко им можно только помешать, усложняя программу собст- 
венными дополнениями. Короче говоря, что бы вы ни делали с программой, выпол- 
няйте измерения, чтобы убедиться в эффективности вносимых изменений. 
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Объединяйте вычисление одинаковых подвыражений. Если в фрагменте кода 
несколько раз вычисляется одно и то же сложное выражение, проделайте вычисле- 
ния один раз и запомните результат. Например, в главе 1 демонстрировался макрос, 
который вычислял расстояние, причем в нем дважды вызывалась функция вахте. 
По сути, вычислялось следующее выражение: 


2 ѕагі (ах*ах + ау*ау) + ((ѕаге (ах*ах + ау*ау) > 0) ? ...) 


Следовало бы вычислить квадратный корень один раз и воспользоваться резуль- 
татом в двух местах. 

Если вычислительная операция выполняется в цикле, но не зависит от перемен- 
ных параметров цикла, вынесите эту операцию за его пределы. Мы проделали это 
при реорганизации следующего оператора: 


Ғог (і = 0; і < пзбагііпа [с]; і++) { 
После реорганизации этот фрагмент стал выглядеть так: 


п = пзбакЕ1та [с]; 
Бог (і = 0; і < п; 1++) { 


Заменяйте дорогостоящие операции на более простые. Одним из видов опти- 
мизации является упрощение операций. В минувшие времена это, например, означа- 
ло замену умножения сложением или сдвигом, хотя в наши дни это редко окупается. 
Однако деление и взятие остатка выполняются намного медленнее, чем умножение, 
поэтому определенного улучшения можно добиться, заменив деление умножением 
на обратную величину, а взятие остатка — операцией наложения битовой маски, 
если делитель является степенью двойки. Замена обращения к массиву по индексу с 
использованием указателя в С или С++ может дать некоторое ускорение, хотя 
большинство компиляторов и так делают это автоматически. Замена вызова функ- 
ции более простой вычислительной операцией все еще может иметь смысл. Расстоя- 
ние между точками на плоскости определяется формулой загі (ах*ах+ау*ау), 
поэтому решение вопроса о том, какая из двух пар точек расположена на большем 
расстоянии, обычно включает в себя вычисление двух квадратных корней. Однако 
то же самое решение можно принять, сравнивая квадраты расстояний. Следующий 
оператор дает тот же результат, что и сравнение квадратных корней: 


1Е (94х1*ах1+Аау1*ау1 < ах2*ах2+ау2*ау2) 


Еще один пример подобной оптимизации встречается в системах поиска задан- 
ных текстовых образцов наподобие нашего спам-фильтра или утилиты дгер. 
Если такой образец начинается с литерального символа, то вначале выполняется 
быстрый поиск во входном тексте по этому первому символу. Если символа в тексте 
нет, то более сложный механизм поиска всего образца вообще не активизируется. 


Разворачивайте или устраняйте циклы. При организации и выполнении цик- 
лов затрачивается некоторое дополнительное время и ресурсы системы. Если тело 
цикла достаточно короткое и выполняется лишь несколько раз, то бывает быстрее 
просто выписать все итерации одна за другой в исходном коде. Рассмотрим следую- 
щий пример: 
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Ғор (і = 0; і < 3; 1++) 
а[1] = Ь[і] + с[ 1]; 


Его можно переписать в таком виде: 


а [0] р[0] + с 0]; 
а[1] [1] + <[1]; 
а [2] = Ь[2] + с[2]; 


Такая запись устраняет дополнительные расходы по организации цикла, в част- 
ности, по его ветвлению, которое может замедлить современный процессор, преры- 
вая непрерывный поток вычислений. 

Если цикл имеет большую длину, аналогичное преобразование МОЖНО ИСПОЛЬЗО- 
вать для сокращения количества итераций: 

Ғог (і = 0; і < 3*п; 1++) 
а[1] = Ы[і] + с[і]; 


После реорганизации цикл будет выглядеть так: 


Ғор (і = 0; 1 < Зжп; і += 3) { 


а [1+0] = 6[1+0] + с[1+0]; 
а [1+1] = Ь[їі+1] + с[1+1]; 
а [1+2] = Ь[1+2] + с[1+2]; 


} 


Заметьте, что данный конкретный прием срабатывает только тогда, когда про- 
должительность цикла кратна количеству операторов в его теле. В противном случае 
необходим дополнительный код для состыковки в конце, а это провоцирует ошибки 
и снижение быстродействия. 


Кэшируйте часто используемые данные. Кэшированные значения нет необходи- 
мости пересчитывать заново. При кэшировании используется преимущество локально- 
сти, т.е. тенденции программ (как и людей) снова и снова обращаться к недавно ис- 
пользованным или близлежащим объектам и данным в противовес более старым или 
отдаленным. В вычислительной технике кэш-память применяется очень широко; 
установка дополнительной кэш-памяти на компьютер может существенно ускорить 
работу системы. То же справедливо и для программ. Например, МеЬ-браузеры кэши- 
руют страницы и графические изображения, чтобы сэкономить на медленной пере- 
сылке данных по Іпќегпеё. В программе предварительного просмотра печатного доку- 
мента, которую мы написали много лет назад, выполнялся поиск в таблице таких 
неалфавитных специальных символов, как '/, . Как показали замеры быстродействия, 
большей частью применение специальных символов состояло в вычерчивании линий 
из длинных цепочек одного и того же символа. Кэширование всего одного — самого 
последнего — из использованных символов сразу же сделало программу существенно 
быстрее на большинстве типичных наборов входных данных. 

Лучше всего сделать так, чтобы операция кэширования была невидима внешнему 
пользователю и внешним модулям. В этом случае остальная часть программы никак не 
будет затронута этой операцией, за исключением общего повышения быстродействия. 
Так, в случае программы предварительного просмотра печати интерфейс функции 
вывода символов никак не менялся; он всегда выглядел следующим образом: 


агамсћһаг (с); 
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В исходной версии ахамсвах выполнялся вызов зВом (1оокир (с) ). В реализа- 
ции с кэшированием использовались дополнительные внутренние статические 
переменные, в которых запоминался предыдущий символ и его код: 

1Е (с != 1аѕіс) { /* црдабе сасћһе */ 


Іаѕіёс = с; 
1азесоае = 1оокир (с); 


ѕћом (1азёсоае); 


Пишите свои функции распределения памяти. Часто единственной горячей 
точкой программы является распределение памяти, проявляющееся в виде большого 
количества вызовов функции та11ос или обращений к операторам пем. Если в 
большинстве запросов требуются блоки одного и того же размера, то можно добить- 
ся существенного ускорения путем замены общих функций распределения памяти 
специальными. Такая специальная функция выполняет один вызов та11ос, получа- 
ет один большой массив блоков, а затем раздает их по одному по мере необходимо- 
сти, что в итоге обходится проще и дешевле. Освобожденные блоки возвращаются в 
список, чтобы их можно было быстро задействовать снова. 

Если размеры запрашиваемых блоков близки, но не одинаковы, можно сэконо- 
мить время за счет некоторого увеличения объема памяти. Для этого следует выде- 
лять фиксированный максимальный объем памяти для каждого блока. Этот подход 
бывает эффективен при работе с короткими строками. В этом случае они помещают- 
ся в буферы фиксированного размера, равного длине наибольшей строки. 

В некоторых алгоритмах, в которых сначала запрашивается сразу много буферов 
памяти, а потом они все сразу освобождаются, можно использовать стековую модель 
распределения памяти. В этом случае модуль распределения памяти получает в свое 
распоряжение один большой массив и рассматривает его как стек, одним махом по- 
мещая в него новые объекты в начале и извлекая освобождаемые в конце программы. 
В некоторых библиотеках С для этой цели имеется функция а11оса, хотя она 
не относится к числу стандартных. В ней в качестве источника памяти используется 
локальный стек модуля, и все размещенные объекты освобождаются, как только 
функция, вызвавшая а11оса, возвращает управление. 


Буферизуйте ввод и вывод. Буферизация объединяет операции в пакет, так что 
часто выполняемые манипуляции с данными организуются по максимально эффек- 
тивному графику, а очень затратные операции выполняются только в случае край- 
ней необходимости. Таким образом, затраты на выполнение ввода-вывода равно- 
мерно распределяются по целым наборам данных. Например, когда в программе на 
С вызывается функция ргіпе Е, символы помещаются в буфер, но не передаются в 
операционную систему до тех пор, пока буфер не наполняется или не сбрасывается в 
поток вывода принудительно. В свою очередь, операционная система также может 
задержать запись данных на диск. Недостаток этого подхода состоит в том, что необ- 
ходимо очистить буфер вывода, чтобы сделать данные видимыми пользователю. 
В самом худшем случае информация, все еще находящаяся в буфере, будет потеряна, 
если программа завершится аварийно. 
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Обрабатывайте особые случаи отдельно. Путем обработки объектов одного 
размера в отдельном модуле кода функции специального распределения памяти 
помогают снизить затраты времени и ресурсов в функциях общего назначения, 
атакже иногда уменьшают фрагментацию памяти. В графической библиотеке для 
системы шегпо базовая функция прорисовки была сначала написана как можно 
проще и очевиднее. Как только эта версия заработала, по одной стали добавляться 
оптимизации для различных специальных случаев (выделенных путем профилиро- 
вания). Простейшая версия сохранилась, так что оптимизированные варианты все- 
гда можно было сравнить с ней. В конце концов авторы оставили оптимизацию всего 
лишь нескольких случаев, потому что динамическое распределение вызовов функ- 
ции прорисовки сильно склонялось в сторону отображения символов, а писать 
хитроумный код для всех случаев оказалось нерационально. 


Выполняйте предварительные вычисления. Иногда программу можно сделать 
быстрее, вычисляя некоторые величины заранее, чтобы они были уже под рукой в 
момент, когда они понадобятся. Этот принцип применялся в спам-фильтре, в кото- 
ром величина зЕх1еп (раї [1] ) вычислялась заранее и помещалась в позицию мас- 
сива рае1еп [1]. Если графической системе необходимо постоянно пересчитывать 
значения математической функции наподобие синуса, но лишь для дискретного 
набора аргументов, например целого числа градусов, то быстрее будет заранее про- 
считать таблицу из 360 позиций (или предоставить ее в виде исходных данных) 
и обращаться к ней по индексам. Это типичный пример экономии времени за счет 
используемого объема памяти. Существует множество возможностей для замены 
кода данными или выполнения вычислений при компиляции для экономии времени 
выполнения, а иногда и ресурсов памяти. Например, функции семейства сёуре на- 
подобие 139191 почти всегда реализуются в виде обращения к таблицам битовых 
флагов, а не с помощью сравнений и других вычислительных операций. 


Используйте приближенные значения. Если точность вычислений не имеет 
решающего значения, используйте типы данных меньшей точности, т.е. разрядности. 
В старых или небольших системах, как и в тех, где вещественнозначные операции 
выполняются программно, а не аппаратно, вещественная арифметика одинарной 
точности часто работает быстрее, чем арифметика двойной точности. Поэтому для 
экономии времени можно воспользоваться типом Ё1оа* вместо аоцЬ1е. В некото- 
рых современных программах для работы с графикой используется аналогичный 
прием. Стандарт ІЕЕЕ по вещественной арифметике предписывает “корректную 
обработку потери значимости” при приближении результата вычислений к нижней 
границе представляемых значений. Однако это обходится недешево. При обработке 
изображений подобная операция не имеет никакого смысла. Целочисленные функ- 
ции вычисления синуса и косинуса — это еще один пример приближенных вычисле- 
ний этого рода. 


Переписывайте части программы на языке более низкого уровня. Языки 
более низкого уровня имеют тенденцию к большему быстродействию, хотя это дос- 
тигается за счет рабочего времени программиста. Поэтому переписывание отдель- 
ных критических модулей программы, написанной на С++ или ]ауа, на языке С или 
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замена интерпретируемого сценария скомпилированной программой может значи- 
тельно улучшить быстродействие. 

Иногда можно получить существенное повышение быстродействия, используя 
машинно- или системно-зависимый код. Это самое крайнее средство, и прибегать к 
нему без нужды не следует, потому что из-за этого ухудшается переносимость и за- 
трудняется доработка и поддержка программы. Почти всегда те модули, которые 
желательно переписать на языке ассемблера, являются сравнительно небольшими 
функциями, легко встраиваемыми в какую-нибудь библиотеку. Типичными приме- 
рами являются метзее, тештоте и графические операции. Основной подход состо- 
ит в следующем. Необходимо написать код так чисто и правильно, как только воз- 
можно, целиком на языке высокого уровня и полностью протестировать его, как это 
описано в главе 6 для функции тетзе+. Это будет переносимая версия, работающая 
на любых платформах, хотя и медленно. Таким образом, при переходе в новую среду 
можно будет начинать с гарантированно рабочей версии программы. Написав вер- 
сию с применением языка ассемблера, протестируйте ее на полную эквивалентность 
переносимой версии. Если случаются ошибки, под подозрение всегда попадает непе- 
реносимая часть кода, и здесь полезно иметь эталонную версию для сравнения. 


Упражнение 7.4. Один из способов повысить быстродействие такой функции, 
как тетѕеб, — это заставить ее записывать данные словами, а не байтами. Этот спо- 
соб лучше совместим с аппаратурой и может снизить дополнительные затраты при 
организации циклов в четыре-восемь раз. Недостаток этого подхода состоит в том, 
что если блок назначения не выровнен по границе слова или его длина не кратна 
длине слова, то возникают различные побочные эффекты. Напишите версию этой 
функции, оптимизированную данным способом. Сравните ее быстродействие с 
существующей библиотечной версией и простым циклом побайтовой записи. 


Упражнение 7.5. Напишите функцию распределения памяти зта11ос для строк 
С, в которой бы использовался специальный модуль распределения для небольших 
строк, но прямой вызов та11ос — для больших. Необходимо будет определить 
структуру для представления строк в каждом случае. Как принять решение, в каком 
случае переключаться с ѕзта11ос на та] 1ос? 


7.5. Оптимизация использования памяти 


В свое время память была самым драгоценным вычислительным ресурсом. 
Ее всегда не хватало, и при попытках выжать максимальный результат из того мало- 
го, что имелось в наличии, было написано немало плохих программ. В качестве ха- 
рактерного примера часто приводят пресловутую “проблему 2000 года”: когда памя- 
ти действительно ни на что не хватало, даже экономия двух байт на представлении 
цифр 19 казалась существенной. Но независимо от того, действительно ли причиной 
проблемы была попытка сэкономить память (а это могло быть вызвано и простой 
привычкой опускать столетия в датах в повседневной жизни), это хороший пример 
близорукой, недальновидной оптимизации. В любом случае, времена изменились, и 
теперь как оперативная, так и внешняя память стоят удивительно дешево. Поэтому 


Раздел 7.5 Оптимизация использования памяти 213 


первый принцип оптимизации использования памяти должен быть таким же, как и в 
отношении быстродействия, — постарайтесь вообще ее не делать. 

Однако бывают и ситуации, когда эффективность использования памяти все- 
таки имеет значение. Если программа не помещается в оперативную память, то от- 
дельные ее части будут храниться в виртуальной памяти на диске, что сделает быст- 
родействие недопустимо низким. Это можно часто видеть при установке новых вер- 
сий программ; после обновления они тут же начинают расходовать память. Суровая 
реальность такова, что вслед за модернизацией программного обеспечения часто 
приходится покупать дополнительную память. 


Экономьте память, используя наименьший возможный тип данных. Первый 
шаг к эффективности использования памяти — это оптимизировать работу с уже 
задействованными ресурсами, например, применяя самые короткие типы данных, 
пригодные для решения задачи. Например, тип 11 заменяется типом знохге, если в 
него помещаются рабочие данные, такие как координаты в системах работы с дву- 
мерной растровой графикой, поскольку 16 бит наверняка хватит для работы с лю- 
бым возможным диапазоном экранных координат. Тип ЯоцЪ1е также иногда заме- 
няется типом Е1оа(; потенциальная проблема состоит в потере точности, поскольку 
для чисел типа Е1оае обычно запоминается всего 6 или 7 значащих десятичных 
цифр. В этих и аналогичных случаях могут понадобиться также и другие изменения, 
самые заметные из которых — замена спецификаций формата в вызовах функций 
ре1пЕЕ и особенно зсапЕ. 

Этот подход применим и к представлению логической информации. Ее можно 
кодировать одним байтом или отдельными битами, по возможности одним. Не 
следует пользоваться битовыми полями С и С++; они очень плохо переносимы и 
приводят к генерированию слишком громоздкого кода. Вместо этого следует инкап- 
сулировать требуемые операции в функциях, которые бы устанавливали или запра- 
шивали отдельные биты машинного слова или массива слов с помощью операций 
поразрядного маскирования и сдвига. Следующая функция возвращает группу по- 
следовательных битов из середины слова: 

/* десріёѕ: получает п бит из позиции р */ 


/* биты нумеруются с 0, начиная с младших */ 
1151апеа 1п6 чееЬ1ез (ипѕідпеа 116 х, іпе р, іпе п) 


геёцгп (х >> (р+1-п)) & -(-0 << п); 


} 


Если такие функции работают слишком медленно, их можно усовершенствовать с 
помощью методов, описанных ранее в этой главе. В языке С++ для представления дос- 
тупа кбитам в виде обращения по индексу можно использовать перегрузку операций. 


Не храните данные, которые легко вычислить заново. Подобные изменения 
имеют локальный и частный характер; они аналогичны тонкой настройке кода. 
Более глобальные усовершенствования обычно связаны с перестройкой структур 
данных, иногда вместе с изменением алгоритма. Вот один пример. Много лет назад к 
одному из нас обратился коллега, который пытался выполнить вычисления над 
такой большой матрицей, что только для того, чтобы она поместилась в память, при- 
ходилось выключать компьютер и загружать урезанную операционную систему. 
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Ему хотелось знать, нет ли какой-нибудь разумной альтернативы, потому что работа 
в подобном режиме походила на кошмар. Мы спросили, что представляет собой эта 
матрица, и оказалось, что она содержит целочисленные значения, причем большей 
частью нули. Фактически ненулевыми были менее пяти процентов элементов 
матрицы. Сразу же возникла идея представления матрицы, в котором хранились бы 
только ненулевые элементы, а каждое обращение по индексам м [1] [5 ] заменялось 
бы вызовом функции т (і, ј). Существует несколько способов хранить подобные 
данные. Самый простой из них — это массив указателей, по одному на каждую стро- 
ку, которые указывают на компактный массив из номеров столбцов и соответствую- 
щих чисел. В этом представлении на каждый ненулевой элемент в среднем затрачи- 
вается больше памяти, но в целом матрица занимает значительно меньше места. 
Хотя обращение к отдельным элементам несколько замедляется, в целом процедура 
становится намного быстрее, чем перезагрузка операционной системы. Короче гово- 
ря, наш коллега применил предложенный способ и остался вполне доволен. 

Мы применили подобный способ для решения современного варианта той же 
проблемы. В системе проектирования радиосетей необходимо было представить 
ландшафтную информацию и интенсивность радиосигнала в большом географиче- 
ском регионе (от 100 до 200 км по стороне) с разрешением около 100 метров. 
Хранить подобную информацию в большом прямоугольном массиве означало пре- 
высить объем памяти, имеющийся в системе, и вызвать недопустимые затраты вре- 
мени на ее виртуализацию. Но оказалось, что в довольно больших регионах ланд- 
шафт и интенсивность сигнала имеют тенденцию сохраняться постоянными, так что 
проблема оказалась решаемой с помощью иерархического представления, в котором 
регионы с одними и теми же показателями объединялись в одну ячейку. 

Вариации на эту тему весьма распространены, как и конкретные представления 
данных, но все их объединяет общая идея: хранить тривиальные, общие значения 
неявно или в компактной форме, пожертвовав несколько большим временем и 
ресурсами на обработку остальных значений. Если большую часть данных действи- 
тельно составляют общие значения, эта стратегия имеет успех. 

Программу следует организовать так, чтобы конкретное представление данных 
сложного типа было инкапсулировано в классе или наборе функций, оперирующих с 
закрытыми типами или наборами данных. Эта мера предосторожности необходима 
для того, чтобы остальная часть программы не была затронута при возможном 
изменении представления данных. 

Иногда проблемы экономии памяти появляются также и при внешнем представ- 
лении информации — как преобразовании, так и хранении. В целом всегда лучше 
хранить информацию в текстовом виде, когда возможно, чем в двоичном представ- 
лении какого бы то ни было вида. Текст лучше переносится между системами, легко 
читается, поддается обработке любыми средствами. У двоичных представлений нет 
ни одного из подобных преимуществ. Аргументы в пользу двоичных представлений 
обычно основываются на преимуществах “скорости обработки”, но к ним следует 
относиться скептически, поскольку разница в скорости между текстовой и двоичной 
формой может оказаться совсем не такой большой. 

Некоторая экономия часто достигается за счет жертвования временем выполне- 
ния. Так, в одном приложении необходимо было передавать большое изображение 
из одной программы в другую. Изображения в простом формате (РРМ) обычно 
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занимали около мегабайта, поэтому нам показалось, что будет быстрее закодировать 
их для пересылки в сжатом формате СТЕ, в котором файлы занимали около 50 кило- 
байт. Но кодирование и декодирование СТЕ-формата отнимало столько же времени, 
сколько экономилось путем передачи более короткого файла, так что никакой 
экономии, по сути, не достигалось. Код для обработки СІЕ-формата имел длину 
около 500 строк, а для работы с РРМ-форматом — примерно 10 строк. Поэтому для 
удобства работы с программой идея с СТЕ-кодированием была отброшена, и в при- 
ложении продолжал использоваться исключительно формат РРМ. Разумеется, мы 
пришли бы совсем к другим выводам, если бы файл нужно было пересылать по мед- 
ленной сети. Тогда формат СІЕ имел бы большое преимущество. 


7.6. Некоторые оценки 


Заранее оценить, насколько быстро будет работать программа, очень трудно, 
аеще труднее оценить затраты на конкретные операторы языка или машинные 
инструкции. Тем не менее довольно просто построить модель стоимости языка или 
системы, которая даст, по крайней мере, грубое представление о продолжительности 
выполнения важнейших операций. 

В традиционных языках программирования часто используется следующий под- 
ход: пишется программа, измеряющая время выполнения типичных, представитель- 
ных фрагментов кода. Здесь имеются некоторые операционные трудности, напри- 
мер, получение надежно воспроизводимых результатов и отфильтровывание 
накладных затрат времени. Но тем не менее можно получить полезные оценки без 
особых усилий. Например, у нас есть программа для составления модели стоимости 
языков С и С++, которая оценивает затраты на отдельные операторы. Для этого 
операторы заключаются в цикл и выполняются много миллионов раз, а затем вы- 
числяется среднее время. На компьютере МІРЅ К10000 с тактовой частотой 
250 МГц были получены следующие данные, в которых длительность операций 
указана в наносекундах: 


Іп Орегаёіопѕ 


11++ 8 
11 = 12 + 13 12 
11 = 12 - 13 12 
11 = 12 * 13 12 
11 = 12 / із 114 
11 = 12% 13 114 
Е1оаЕ Орегабіопѕ 
Е1 = Е2 8 
Е1 = Е2 + ЕЗ 12 
Е1 = Е2 - ЕЗ 12 
Ғ1 = #2 * ЕЗ 11 
Е1 = #2 / #З 28 
РоцЬ1е Орегабіопѕ 
41 = 42 8 
91 = 42 + аз 12 
а1 = 42 - аз 12 
а1 = 42 * аз 17 
а1 = 42 / аз 58 
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Мотегіс Сопуегѕіопѕ 
О = ЕЛ 8 
Ле 8 


Целочисленные операции — достаточно быстрые, за исключением деления и взя- 
тия остатка. Операции над вещественными числами с плавающей точкой, как оказа- 
лось, почти настолько же быстры. Это немалый сюрприз для людей, выросших в 
убеждении, что такие операции обходятся намного дороже, чем целочисленные. 

Другие базовые операции также выполняются довольно быстро. В их числе — 
вызовы функций, последние три строки следующей группы: 


Іпбедег Уесіог Орегаііопѕ 


у[1] = і 49 
м [У [1]] = і 81 
м [М [У [1]]] = 1 100 
Сопёгої 5Ехисбагкез 
ЇЁ (і == 5) 11++ 4 
ЗЕ (і != 5) 11++ 12 
мһі1е (і < 0) і1++ 3 
11 = ѕит1 (12) 57 
11 = ѕит2 (12, 13) 58 
11 = ѕитз (12, 13, 14) 54 


А вот операции ввода-вывода не столь дешевы, как и другие библиотечные функции: 


Тприе /Оцерие 
Ериёз (5, Ёр) 270 
Ғдеѕ (5, 9, Ер) 222 
Ғргіпіғ (Ёр, "%а\п", 1) 1820 
ЕзсапЕ (Ёр, "%а", &11) 2070 
Ма11ос 
Ғгее (та11ос (8)) 342 
Ѕігіпа Ғопсбіопѕ 
ѕігсру (3, "0123456789") 157 
11 = зігстр(ѕ, $5) 176 
11 = зегстр (3, "а123456789") 64 


5Ех1п9/Машьег Сопуегѕіопѕ 


11 = або] ("12345") 402 
ѕѕсапї ("12345", "%а", &11) 2376 
ѕргіпі# (5, "%а", 1) 1492 
Е1 = абоЕ ("123.45") 4098 
ззсапЕ ("123.45", "%Ё", &Е1) 6438 
зрг1пЕЁ (з, "%6.2Е", 123.45) 3902 


Измерения для та11ос и Егее, по всей видимости, не показывают их истинного 
быстродействия, поскольку освобождение памяти сразу после ее выделения — нети- 
пичная операция. 
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Наконец, вот результаты для математических функций: 


Маһ Ецпсёіопѕ 


11 = гапа () 135 
Е1 = 109 (#2) 418 
Е1 = ехр(#2) 462 
Е1 = ѕіп(#2) 514 
Ғ1 = зак®(Е2) 112 


На другой аппаратной платформе эти значения, конечно, были бы другими. Однако 
эти цифры можно использовать для прикидочных расчетов времени выполнения от- 
дельных фрагментов программ, для сравнения относительных затрат на ввод-вывод и 
на основные вычислительные операции или для принятия решения о том, переписы- 
вать ли выражение в другом виде или использовать встраиваемую функцию. 

Данные оценки варьируются по самым разным причинам. Одна из них — это уро- 
вень оптимизации, устанавливаемый при компиляции. Современные компиляторы 
могут проделывать такие оптимизации, о которых программисты даже не догадыва- 
ются. Более того, современные процессоры устроены так сложно, что только хоро- 
шие компиляторы могут в полной мере воспользоваться их возможностями: выпол- 
нять несколько инструкций одновременно, конвейеризировать их выполнение, дос- 
тавлять инструкции и данные в регистры или кэш-память до их выполнения и т.п. 

Еще одна причина, по которой трудно заранее предсказать быстродействие, — 
это сама архитектура вычислительных систем. Качество кэш-памяти очень сильно 
влияет на быстродействие; проектировщики компьютеров напрягают все силы, что- 
бы как-то справиться с тем обстоятельством, что оперативная память намного мед- 
леннее кэш-памяти. Сама по себе тактовая частота процессора (например, 400 МГц) 
хотя и говорит о быстродействии кое-что, но далеко не все. Один из наших старых 
компьютеров Реп ит с частотой 200 МГц работает гораздо медленнее еще более 
старого Репиит-100 только потому, что у второго имеется большая кэш-память вто 
рого уровня, тогда как у первого ее нет. К тому же различные поколения процессо- 
ров используют разное количество тактов для выполнения тех или иных операций, 
даже если наборы инструкций в них совпадают. 


Упражнение 7.6. Разработайте набор тестов для оценки стоимости базовых опе- 
раций в тех компьютерах и компиляторах, которые вам доступны. Исследуйте сход- 
ство и различие в их быстродействии. 


Упражнение 7.7. Разработайте модель стоимости средств высокого уровня 
в С++. Среди таких средств — создание объектов классов с помощью конструктора, 
их копирование и удаление; вызовы функций-методов; виртуальные функции; 
встраиваемые 1п11пе-функции; библиотека 1озЕгеат; библиотека ТІ. Эта зада- 
ча, в принципе, не имеет конца, поэтому сосредоточьтесь на небольшом наборе пред- 
ставительных операций. 


Упражнение 7.8. Повторите предыдущее упражнение для языка Јаха. 
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7.7. Резюме 


Если для программы выбран правильный, соответствующий задаче алгоритм, то 
оптимизация быстродействия — это обычно последнее, о чем следует беспокоиться 
при написании программы. Но если уж приходится ею заниматься, то общая проце- 
дура выглядит примерно так: провести измерения, сосредоточиться на нескольких 
местах, где оптимизация будет иметь наибольший эффект, проверить корректность 
внесенных изменений, а затем снова провести измерения. Не увлекайтесь оптимиза- 
цией; остановитесь так быстро, как это возможно. Сохраните простейшую версию 
как эталон для измерения времени и верификации. 

При попытке оптимизировать быстродействие программы или потребления ею па- 
мяти полезно выполнять эталонные тесты и задачи, оценивая эффективность работы 
программы со своей точки зрения. Если для вашей задачи уже существуют стандарт- 
ные тесты, воспользуйтесь ими. Если программа сравнительно автономна в своей ра- 
боте, можно найти или разработать серию “типичных” наборов входных данных. 
Их можно включить и в серию рабочих, не эталонных тестов. Именно так организуется 
процесс эталонного тестирования коммерческих и научно-исследовательских систем 
типа компиляторов, расчетных программ и т.п. Например, вместе с АмК поставляется 
примерно 20 небольших программ, которые в совокупности охватывают все часто ис- 
пользуемые средства языка. Эти программы выполняются над очень большим файлом 
входных данных, чтобы проверить эквивалентность получаемых результатов и отсут- 
ствие проблем с быстродействием. У нас также имеется коллекция стандартных боль- 
ших файлов данных, которые можно использовать для тестов по измерению времени. 
В некоторых случаях полезно сделать так, чтобы эти файлы имели легко контроли- 
руемые свойства, например, длину, кратную десяти или двум. 

Эталонные тесты можно проводить с помощью таких же оболочек, как те, кото- 
рые рекомендованы для тестирования в главе 6, или аналогичных им. Тесты по из- 
мерению времени должны выполняться автоматически; в выходных данных должно 
содержаться достаточно информации для их полного понимания и воспроизведения; 
следует также вести регистрационные записи для отслеживания эволюционных тен- 
денций и критическихх изменений. 

Кстати, хорошие эталонные испытания провести очень трудно. Бывают фирмы, 
настраивающие свои программные продукты исключительно под эталонные тесты. 
Поэтому опубликованные результаты любых таких тестов следует воспринимать 
критически. 


Дополнительная литература 


Рассмотренный нами спам-фильтр основан на работе Боба Фландрены 
(ВоБ Е1апагепа) и Кена Томпсона (Кеп Тћотрѕоп). Их алгоритм фильтрации вклю- 
чает в себя регулярные выражения для более сложного поиска соответствий, а также 
автоматическую классификацию сообщений (гарантированный спам, вероятный 
спам, не спам) в соответствии с обнаруженными строками. 
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Статья Д. Кнута (О. Кпи В) по профилированию под названием “Ап Етрігіса! 
Ѕєиау о ЕОКТКАМ Ргоргатѕ” была опубликована в журнале боЙате — Рхасйсе апі 
Ехрепепсе, 1971, 1, 2, р. 105-133. Основное содержание статьи составляет статисти- 
ческий анализ программ, обнаруженных в мусорных корзинах и общедоступных 
каталогах вычислительных центров. 

В книгах Дж. Бентли (]оп Вепіеу) Рғортаттіпр Реағ1ѕ и Моте Рговғаттіпа Реатб 
(Аааіѕоп-№еѕ]еу, 1986 и 1988 гг. соответственно) приведены прекрасные примеры 
алгоритмической и настроечной оптимизации, а также имеются полезные очерки 
методов организации работ по оптимизации программ и профилированию. 

Книга Кіск Вос, миег Гоорѕ (АЧ41зоп-\ез]еу, 1997) содержит справочный 
материал по тонкой настройке программ для [ВМ-совместимых компьютеров, хотя 
процессоры эволюционируют так быстро, что приведенные там технические под- 
робности стремительно устаревают. 

Серия книг Джона Хеннесси (]офп Неппеззу) и Дэвида Патерсона (Па\!А 
Раѓѓегѕоп) по архитектуре компьютеров (например, Сотршет Отватгайоп апа Реяеп: 
Тре Нагаюат/$оўќоағе Іпіеғјасе, Могвап КаиНпап, 1997) содержит подробное обсуж- 
дение проблем быстродействия современной вычислительной техники. 


Переносимость 


Наконец, стандартизация — как и взаимное соглашение — является еще 
одним проявлением сильной упорядоченности. Но, в отличие от соглашения, 
современная архитектура впитала стандартизацию как явление, обога- 
щающее саму ее технологию, хотя существуют и немалые опасения из-за 
доминирующего и безжалостного характера стандартизации. 


Роберт Вентури. “Сложности и противоречия в архитектуре” 
(Кофет Уетит, Сотр]ехцу апа Сопігайісііоп іп Агсһіќесіцге) 


Разработка программы, которая бы работала правильно и эффективно, дается 
нелегко. Поэтому как только программа успешно заработала в одной среде, автору 
обычно не хочется прилагать больших усилий при переносе ее на другой процессор, 
компилятор или операционную систему. В идеальном случае программа вообще не 
должна нуждаться ни в каких изменениях. 

Этот идеальный случай называется переносимостью. На практике термин 
“переносимость” обычно подразумевает более мягкие требования: при переносе в 
новую среду программу должно быть легче модифицировать, чем переписать заново. 
Чем меньше изменений требуется, тем лучше переносимой является программа. 

Читатель может удивиться, зачем вообще беспокоиться о переносимости. Если 
программа должна работать только в одной рабочей среде и в заранее определенных 
условиях, то чего ради тратить время на расширение ее области применения? Попы- 
таемся ответить на этот вопрос. Во-первых, всякая успешная программа неизбежно 
может использоваться в самых неожиданных местах и с самыми непредсказуемыми 
целями. Разработка программы более общей, чем это определено в ее техническом 
задании, позволяет меньше дорабатывать ее со временем и дает многочисленные 
удобства в использовании. Во-вторых, операционные среды меняются. Когда ком- 
пилятор, операционная система или аппаратные компоненты подвергаются модер- 
низации, набор рабочих средств системы изменяется. Чем меньше программа зави- 
сит от специфических возможностей системы, тем менее вероятен ее крах в новом 
окружении и тем проще ее адаптация к нему. Наконец, что важнее всего, хорошо 
переносимая программа — это всегда более качественная программа, чем плохо 
переносимая. Усилия, затраченные на улучшение переносимости, обычно приводят 
также к усовершенствованию архитектуры и реализации, а также к более тщатель- 
ному тестированию. Техника программирования хорошо переносимых систем очень 
близка по своим принципам к хорошему стилю программирования в целом. 
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Разумеется, степень переносимости следует выбирать из практических сообра- 
жений. Такого явления, как абсолютно переносимая программа, нет в природе; есть 
только программы, не протестированные в достаточно большом количестве разных 
сред. Но мы все же примем такое определение переносимости, как возможность вы- 
полнения программы без изменений практически в любой операционной среде. Если 
эта цель и не всегда достигается полностью, все же время, потраченное на улучше- 
ние переносимости при написании программы, обязательно окупится позже — хотя 
бы при ее доработке. 

Наша основная мысль такова: постарайтесь писать программу так, чтобы она 
работала на пересечении нескольких различных стандартов, интерфейсов и сред, 
к которым она должна будет приспособиться. Не старайтесь устранить все проблемы 
переносимости добавлением специального кода. Вместо этого адаптируйте програм- 
му к работе в условиях новых ограничений. Используйте абстрагирование и инкап- 
суляцию для заключения неизбежно непереносимого кода в определенные рамки с 
целью более удобного управления им. Если код останется в пределах пересечения 
всех требований, а его зависимость от системы будет локализована, то программа 
станет более корректной и общей, а также потребует минимальных усилий при пе- 
реносе. 


8.1. Язык 


Придерживайтесь стандарта. Первый шаг к хорошей переносимости кода — 
это, конечно, писать на языке высокого уровня, причем строго придерживаться 
стандарта, если таковой существует. Двоичные файлы редко являются переносимы- 
ми, а вот исходный код — вполне. Но и в этом случае способ трансляции программы 
в машинные коды, выполняемой компилятором, не определен строго даже для стан- 
дартизированных языков. В мире практически нет широко распространенных язы- 
ков с одной-единственной реализацией; обычно среды программирования или ком- 
пиляторы создаются и продаются несколькими производителями для нескольких 
различных операционных систем, к тому же со временем выходят все новые версии. 
При этом способы интерпретирования исходного кода могут эволюционировать. 

Почему же стандарт не является строгим определением? Иногда стандарт просто 
неполон и неспособен дать точные определения в сложных случаях взаимодействия 
разных средств языка. Иногда стандарт намеренно сделан нестрогим. Так, тип сһаг в 
Си С++ может иметь знак или быть беззнаковым и даже не обязан состоять ровно из 
8 бит. Отдавая все эти вопросы на откуп авторам компиляторов, часто можно получить 
более эффективные реализации языка и избегнуть наложения излишних ограничений 
на аппаратные компоненты. Правда, жизнь программистов при этом усложняется. 
Политика тех или иных заинтересованных сторон и проблемы технической совмести- 
мости могут приводить к компромиссам, в которых подробности остаются неопреде- 
ленными. Наконец, языки устроены сложно, и их компиляторы также; поэтому случа- 
ются как недочеты в интерпретации, так и ошибки в реализации. 

Иногда языки бывают вообще не стандартизированы. Так, у языка С есть офици- 
альный стандарт А№51/180, утвержденный в 1988 г., однако стандарт [$0 для языка 
С++ ратифицирован только в 1998 г. Во время написания этой книги далеко не все 
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используемые компиляторы поддерживали официально утвержденную версию. 
Язык Јауа совсем новый, и до его стандартизации еще должны пройти годы. Стан- 
дарт языка обычно разрабатывается только после того, как появился целый ряд 
конфликтующих между собой реализаций, требующих согласования; при этом язык 
должен быть достаточно широко распространен, чтобы затраты на стандартизацию 
окупились. А пока суд да дело, программы писать все равно надо, и от их приспособ- 
ления к различным средам тоже никуда не деться. 

Итак, хотя справочники и нормативные документы создают у читателя ощуще- 
ние строгой и однозначной спецификации, все же полного определения языка они 
никогда не дают, поэтому в разных реализациях обычно случаются различные, при- 
чем несовместимые, интерпретации стандарта. Иногда попадаются даже ошибки. 
Один из примеров как раз попался под руку, когда мы только писали эту главу. 
Вот эта внешняя декларация является недопустимой в языках С и С++: 


? *х[] = {"арс"}; 


Мы протестировали это выражение на добром десятке компиляторов. В резуль- 
тате лишь некоторые корректно диагностировали отсутствие спецификации типа 
сһаг для переменной х; довольно многие выдали предупреждение о несоответствии 
типов (очевидно, используя старое определение языка, в котором переменная х по 
умолчанию считалась массивом указателей типа іпё); наконец, два или три скомпи- 
лировали этот некорректный код без единой жалобы. 


Программируйте базовыми средствами языка. К сожалению, некоторые ком- 
пиляторы не способны проследить за выполнением этого требования, представляю- 
щим собой важный аспект хорошей переносимости. В языках программирования 
есть “темные углы”, где полно неясностей и неоднозначностей, — например, битовые 
поля в Си С++. Таких мест лучше избегать. Используйте только те средства, для 
которых дано совершенно однозначное и хорошо понятное определение. Такие сред- 
ства, по всей вероятности, общедоступны и ведут себя одинаково во всех средах. 
Именно их мы будем называть базовыми средствами языка. 

Определить все базовые средства сразу не так-то просто; гораздо легче выявить 
конструкции, наверняка не входящие в их число. Совершенно новые средства, 
например комментарии // и ключевое слово сотр1ех в С++, или средства, специ- 
фические для одной архитектуры, наподобие ключевых слов пеаг и Ёаг, практиче- 
ски наверняка вызовут проблемы. Если какое-либо средство языка настолько не- 
обычно или расплывчато определено, что для его понимания приходится обращать- 
ся к консультанту по стандартам, не пользуйтесь им ни в коем случае. 

Здесь мы ограничим наше изложение языками С и С++ — распространенными 
языками общего назначения, широко используемыми для написания хорошо пере- 
носимых программ. Стандарт языка С имеет возраст более десяти лет, да и сам язык 
давно устоялся. Правда, новый стандарт уже находится в работе’, так что следует 
готовиться к новым потрясениям. А вот стандарт С++ совсем свежий’, поэтому нуж- 
но некоторое время, чтобы привести к нему все реализации языка. 


1 Новый стандарт 150/АМ№ЅІ С, о котором идет речь, был принят в 1999 г. Книга написана сще до этого 
события. — Прим. ред. 


2 Принятв 1998 г. — Прим. ред. 
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Что же включают в себя базовые средства С? Обычно так говорят лишь о широко 
распространенном и установившемся стиле программирования на этом языке, одна- 
ко иногда бывает полезно подумать и о будущем. Например, в исходной версии С 
не требовалось объявлять прототипы функций. Функция загЕ объявлялась 
следующей декларацией: 


? аочЬ1е загі (); 


Здесь определен тип возвращаемого значения, но ничего не говорится о парамет- 
рах. В А№ЅІ С были добавлены прототипы функций, в которых следовало указывать 
все данные: 


аочЬ1е загі (доџЬ1е); 


Компиляторы АМ№І С обязаны воспринимать и старый синтаксис, но тем не ме- 
нее лучше писать прототипы для всех функций. Это делает код более безопасным и 
устойчивым, поскольку вызовы функций полностью проверяются на совместимость 
типов, и если их интерфейсы меняются, компилятор это замечает. Допустим, в коде 
выполняется следующий вызов: 


Ғопс (7, РІ); 


Пусть при этом функция Еипс не имеет прототипа; тогда компилятор не сможет 
проверить, вызывается ли Еипс корректно. Если впоследствии библиотека изменит- 
ся и Ёопс будет иметь уже три аргумента, то можно упустить из виду необходимость 
исправить ее вызов, поскольку старый синтаксис не дает возможности проверить 
соответствие аргументов функций. 

Язык С++ намного обширнее, чем С, и стандарт его гораздо новее, поэтому его 
набор базовых средств определить еще труднее. Например, хотя можно ожидать, что 
библиотека ЗТТ. войдет в число таких средств, это произойдет еще не скоро, и неко- 
торые нынешние реализации языка до сих пор ее не поддерживают. 


Избегайте проблематичных возможностей языка. Как уже упоминалось, в 
стандартах некоторые моменты намеренно оставлены неопределенными или недо- 
определенными, обычно для того, чтобы дать разработчикам компиляторов больше 
свободы. Список таких моментов неприятно поражает своей длиной. 


Размеры типов данных. Размеры элементарных типов данных в Си С++ не опре- 
делены. Имеются только следующие базовые правила: 


312еоЕЁ (сһаг) <= з12еоЕЁ (ѕһогі) <= з12еоЕ (1106) <= в12еоЕ (1опа) 
312еоЕ (Ғ1оаб) <= з12еоЕ (аочЪ1е) 


Тип сваг должен иметь длину как минимум 8 бит, ѕћогё и іпе — как минимум 
16, а 1опа — не менее 32. Никакие другие свойства не гарантируются. Отсутствует 
даже требование, чтобы значение указателя помещалось в переменную типа іпе. 

Для конкретного компилятора можно довольно просто выяснить, каковы именно 
размеры типов данных: 

/* з12еоЁ: отображает длины элементарных типов */ 
іпё таіп (уоіа) 


{ 


ри1пЕЕ("сраг %а, зрогЕ %а, 1пЕ $%а, 1опд %а,", 
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ѕілеої (спаг), з12еоЕ (ѕһогі), 

512е0Е (116), $12еоЕ (1опа)); 
рк1пЕЕ(" Ғ1оас %а, доџр1е %а, уоіа* %а\п", 

3512еоЕ (Ғ1оаі), з12еоЕ (аоцр1іе), з12еоЕ (уоіа *)); 
гебатп 0; 


} 


Эта программа выдает одни и те же результаты в большинстве систем, которыми 
мы регулярно пользуемся: 


сһаг 1, ѕһогі 2, іпі 4, 1опа 4, Ѓ1оа 4, аоцр1е 8, уо1а* 4 


Но возможны и другие значения. Некоторые 64-разрядные системы выдают 
такой результат: 


сһаг 1, ѕһоүі 2, 11% 4, 1опа 8, Е1оае 4, аойЪ1е 8, уо1а* 8 


Старые компиляторы для персональных компьютеров ІВМ РС обычно давали 
следующий ответ: 


сһаг 1, ѕһоүі 2, іпі 2, 1опа 4, Е1оае 4, аоц1е 8, уо1а* 2 


В ранние годы существования персональных компьютеров их аппаратура подер- 
живала несколько видов указателей. Чтобы справиться с этой неразберихой, были 
придуманы модификаторы пеаг и Ёахк, ни один из которых не является стандарт- 
ным. Тем не менее эти призраки прошлого все еще обитают в нынешних компилято- 
рах, поскольку являются зарезервированными ключевыми словами. Если ваш ком- 
пилятор может изменять размеры элементарных типов, или если в вашем распоря- 
жении есть системы с разными размерами, попытайтесь скомпилировать и 
протестировать вашу программу в этих различных конфигурациях. 

В стандартном заголовочном файле зеааеЕ.в определен ряд типов, помогаю- 
щих улучшить переносимость. Наиболее часто используемым из них является 
ѕіғе Е — целочисленный тип без знака, возвращаемый операцией ѕігеоѓ. Также 
значения этого типа возвращаются функциями наподобие зех1еп и служат аргу- 
ментами многих других функций, включая та11ос. 

Поучившись на ошибках других, авторы Јауа четко определили размеры всех базовых 
типов данных: 8 бит для рубе, 16 — для сһаги зВоге®, 32 — для 116 и 64 — для 10опд. 

Здесь мы не будем обсуждать богатый набор потенциальных проблем, связанных 
с вещественнозначными операциями с плавающей точкой, поскольку эта тема могла 
бы занять отдельную книгу. К счастью, большинство современных систем поддер- 
живает стандарт ІЕЕЕ для аппаратных компонентов, предназначенных для вещест- 
венных операций, так что характеристики вещественнозначной арифметики опреде- 
лены довольно неплохо. 


Порядок вычисления выражений. В языках С и С++ порядок вычисления 
операндов выражений и аргументов функций, а также некоторых других значений 
не определен. Рассмотрим следующее присваивание: 


? п = (ессһагү() << 8) | еёсһаү(); 
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Вторая функция деёсћаг могла быть вызвана первой, поскольку порядок записи 
выражения не всегда совпадает с порядком его выполнения. Еще один пример: 


2 рег [соцпё] = пате [++соцпЕ] ; 


Здесь переменная соцпс может вычисляться до или после ее использования 
в качестве индекса массива рі. Рассмотрим следующий оператор для немедленного 
вывода введенных символов: 


? ре1пЕЕ("%с %с\п", деёсһаг(), десһаг()); 


В нем первый введенный символ вполне может выводиться вторым, а не первым. 
А вот оператор с намеренно сделанной ошибкой выполнения: 


? ре1пЕЕ("%Е %5\п", 109(-1.23), зЕхеггох (еггпо)); 


Здесь значение еггпо может вычисляться еще до вызова функции 109. 

Выполнение некоторых выражений подчиняется определенным правилам. 
По определению все побочные эффекты и вызовы функций должны завершаться к 
моменту, когда в программе встретится очередная точка с запятой, или к следующе- 
му вызову функции. Операции && и | | выполняются слева направо, причем только 
в той степени, в которой это необходимо для вычисления всего выражения (включая 
и побочные эффекты). В операторе ? : вычисляется условие (учитывая сторонние 
эффекты) и только затем вычисляется строго одно из следующих после точки с 
запятой выражений. 

В языке Јауа порядок вычислений определен значительно строже. В нем требует- 
ся, чтобы все выражения, включая побочные эффекты, вычислялись слева направо. 
Тем не менее один авторитетный справочник советует не полагаться на это правило 
в ответственных случаях. Это вполне здравый совет, если есть хоть какая-то вероят- 
ность, что код будет переводиться на язык С или С++, где подобных гарантий нет. 
Вообще, перевод с одного языка на другой — это экстремальный, но иногда полез- 
ный способ протестировать переносимость алгоритма. 

Наличие знака у типа сћаг. В языках С и С++ не определено, должен ли тип 
сһаг быть знаковым или беззнаковым. От этого могут возникнуть проблемы — 
в частности, при сочетании типов сһаг и іпє, как это происходит при вызове функ- 
ции деёсћһаг () с целым возвращаемым значением. Рассмотрим следующий код: 


? сһаг с; /* должен иметь тип 106 */ 
? с = деісһаг(); 


В результате значение с будет находиться в диапазоне от 0 до 255, если тип сһаг 
не имеет знака, и от -128 до 127 в противном случае. Здесь имеется в виду почти 
универсальная конфигурация 8-битовых символов в системе с дополнением к двум. 
В этом случае возникают неприятные последствия, если символ должен использо- 
ваться в качестве индекса массива или сравниваться с кодом ЕОЕ, который обычно 
определен как -1 в файле зе а1о . в. Например, для раздела 6.1 мы разработали при- 
веденный ниже код, после того как в исходной версии пришлось исправить несколь- 
ко предельных случаев. Так, выражение 5ѕ [1] == ЕОЕ никогда не бывает истин- 
ным, если тип сһаг не имеет знака: 
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? 106 і; 

? сҺаг $[МАХ]; 

А 

? Ғор (і = 0; і < МАХ-1; і++) 

? 1Е ((5[1] = аессһаг()) == '\п' || 8[1] == ЕОР) 
? ргеак; 

? 3[1] = '\0'; 


Если функция сеєсһаг возвратит ЕОЕ, в ѕ [і] будет помещено значение 255 
(ОХЕЕ, т.е. результат преобразования -1 к типу џпѕіспеа сраг). Если элемент 
ѕ [і] имеет тип без знака, его значение так и останется 255, и при сравнении с ЕОЕ 
это даст ложный результат. 

Но даже если тип сһаг имеет знак, приведенный код все равно ошибочен. Да, в 
этом случае сравнение с ЕОЕ даст нужный результат, однако вполне корректный вход- 
ной байт охЕЕ не будет отличаться от ЕОР и может привести к преждевременному за- 
вершению цикла. Итак, независимо от наличия знака у переменных типа сһах, необ- 
ходимо всегда помещать возвращаемое из деесваг значение в переменную типа іпё 
для сравнения с ЕОЕ. Вот как нужно записать этот цикл в переносимой форме: 


1106 с, і; 
сҺаг 5 [МАХ]; 
Ғор (і = 0; і < МАХ-1; 1++) { 
1Е ((с = дебсвак()) == '\пһ' || с == ЕОР) 
ргеак; 
5 = 563 
5[1] = '\0'; 


В языке ]ауа нет модификатора опѕіспед; целочисленные типы в нем имеют 
знак, а 16-разрядный тип сһаг — не имеет. 


Арифметический или логический сдвиг. Сдвиг чисел со знаком вправо с помо- 
щью операции >> может быть арифметическим (копия знакового бита размножается 
в процессе сдвига) или логическим (освобождаемые при сдвиге биты замещаются 
нулями). И снова, научившись на горьком опыте С и С++, создатели ]ауа зарезерви- 
ровали знак >> для арифметического сдвига вправо, а для логического предусмотре- 
ли отдельный знак — >>>. 


Порядок байтов. Порядок следования байтов в типах ѕћогєЄ, 116 и 1опа не оп- 
ределен; байт с самым низким адресом может оказаться как младшим, так и старшим 
значащим байтом. Это зависит от аппаратуры компьютера. Мы обсудим этот вопрос 
более подробно чуть позже в этой же главе. 


Выравнивание членов структур и классов. Выравнивание составных элементов 
внутри структур, классов и объединений не определено полностью; единственное, 
что сказано по этому поводу, — элементы должны следовать в порядке их объявле- 
ния. Рассмотрим следующую структуру: 

егис Х { 
сһаг с; 
116 1; 


}; 
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В ней элемент 1 может иметь смещение 2, 4 или 8 байт от начала структуры. 
Некоторые системы позволяют размещать переменные типа іпе по нечетным адре- 
сам, но большинство требует, чтобы элемент типа, состоящего из п байт, помещался 
по адресу, кратному п. Например, значения типа доџр1е, обычно занимающие 
8 байт, помещаются по адресам, кратным восьми. Кроме всего этого, автор компиля- 
тора может добавить свои собственные модификации, например, вынужденное вы- 
равнивание по соображениям быстродействия. 

Никогда не следует предполагать, что элементы структуры занимают непрерыв- 
ную область памяти. Выравнивание создает “дыры”, поэтому, например, структура Х 
будет содержать как минимум один байт лишней, неиспользуемой памяти. Наличие 
таких “дыр” подразумевает, что структура в целом может занимать больше места, 
чем сумма длин ее элементов, причем ее длина может варьироваться от одной систе- 
мы к другой. При динамическом распределении памяти для такой структуры следу- 
ет запрашивать 512еоЕ (зЕгисе Х) байт, а не $1 2еоЕ (сһаг) + з12еоЕ (11%). 


Битовые поля. Битовые поля настолько зависят от аппаратуры и системы, что 
для обеспечения переносимости ими вообще не нужно пользоваться. 

Этот долгий список смертельных опасностей можно укоротить, следуя несколь- 
ким правилам. Не пользуйтесь побочными эффектами в выражениях, кроме очень 
немногих идиоматических конструкций: 


а[1++] = 0; 
с = *р++; 
*5++ = *6++; 


Не сравнивайте значение типа сһаг с кодом ЕОЕ. Для вычисления длины типа 
или объекта пользуйтесь операцией ѕіғеоѓ. Никогда не выполняйте сдвиг вправо 
над значением со знаком. Позаботьтесь о достаточной длине типа данных для любых 
возможных значений, которые могут присваиваться соответствующей переменной. 


Испытайте несколько компиляторов. Можно вообразить себе, что вам уже по- 
нятны все вопросы переносимости, однако компиляторы способны обнаружить та- 
кие проблемы, которых вы никогда не увидите. Разные компиляторы иногда вос- 
принимают одну и ту же программу по-разному, поэтому следует пользоваться их 
помощью. Включите все предупреждения. Испытайте несколько компиляторов в 
одной и той же системе, а также в разных системах. Скомпилируйте программу на 
языке С компилятором С++. 

Поскольку один и тот же язык может отличаться в средах различных компилято- 
ров, тот факт, что программа компилируется без ошибок одним компилятором, еще 
не гарантирует даже ее синтаксической правильности. Если же несколько компиля- 
торов принимает ваш код без ошибок, ситуация улучшается. Мы компилировали все 
программы на С из этой книги тремя разными компиляторами в трех разных и не 
родственных операционных системах (Опіх, Р]ап 9, Міпаомѕ), а также одним-двумя 
компиляторами С++. Это был весьма отрезвляющий опыт, поскольку все эти ком- 
пиляторы выловили полтора десятка ошибок переносимости, найти которые вруч- 
ную было бы не в силах человеческих. А вот исправление этих ошибок потребовало 
вполне тривиальных усилий. 
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Разумеется, компиляторы могут и сами порождать проблемы совместимости, вы- 
бирая различные варианты нестрого заданных операций. Но наш подход все же обна- 
деживает. Чем писать код таким образом, что различия между системами, средами и 
компиляторами только подчеркиваются и усиливаются, мы пытаемся организовать 
программу так, чтобы она не зависела от среды. Короче говоря, мы попросту пытаемся 
избежать средств и возможностей, подверженных вариациям от системы к системе. 


8.2. Заголовочные файлы и библиотеки 


Заголовочные файлы и библиотеки предоставляют программисту дополнитель- 
ные средства для работы, помимо тех, которые обеспечиваются основным синтакси- 
сом языка. Среди характерных примеров — средства ввода-вывода ѕбадіо в С, 
іоѕёгеат в С++, ИЛИ јауа.іо в ]ауа. Строго говоря, эти средства не являются 
частью самих языков, но определены вместе с ним и должны составлять неотъемле- 
мую часть любой среды, в которой декларируется поддержка этих языков. Но по- 
скольку эти библиотеки охватывают слишком широкий спектр операций и часто 
должны близко взаимодействовать с операционной системой, в них по-прежнему 
скрываются проблемы непереносимости. 


Пользуйтесь стандартными библиотеками. В отношении библиотек приме- 
ним тот же совет, что и для основной части языка: придерживайтесь стандарта, при- 
чем его старых, отработанных компонентов. В языке С определяются стандартные 
библиотеки функций для ввода-вывода, строковых операций, анализа классов сим- 
волов, распределения памяти и ряда других задач. Если ограничить взаимодействие 
программы с операционной системой этими функциями, то вероятность стабильно- 
го, одинакового выполнения кода в разных системах серьезно повышается. Тем не 
менее нужно быть осторожным, потому что существует много реализаций библиотек 
и некоторые из них содержат нестандартные возможности. 

В АМЗГ С не определена функция копирования строк зЕхЧир, однако в боль- 
шинстве сред она существует даже при том, что эти среды декларируют свое полное 
соответствие стандарту. Опытный программист может воспользоваться функцией 
зехаир по привычке, и среда разработки даже не предупредит его о нестандартно- 
сти данного средства. Позже программа не пройдет компиляцию при ее переносе в 
среду, не поддерживающую данную функцию. Именно такого типа проблемы пере- 
носимости обычно связаны с библиотеками. Единственное возможное решение — 
это строго придерживаться стандарта и тестировать программу в самых разнообраз- 
ных рабочих средах. 

Заголовочные файлы и определения пакетов задают интерфейс к стандартным 
функциям. Существует проблема, связанная с загромождением таких файлов, по- 
скольку их авторы стараются удовлетворить требованиям сразу нескольких языков. 
Например, можно обнаружить один файл ѕсдіо.һ, обслуживающий одновременно 
компиляторы старого С, АМЗГ С и даже С++. В таких случаях файл изобилует ди- 
рективами условной компиляции #1Е и #1ЕаеЕ. Язык директив препроцессора 
не отличается гибкостью, поэтому такие файлы трудно читать и понимать, и они 
иногда содержат ошибки. 
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Следующий отрывок из заголовочного файла одной из наших систем лучше дру- 
гих, хотя бы потому, что он хорошо отформатирован: 


? #1ЕАеЕ ор с 

? ехіегп іпё Егеаа(); 

? ехіегп іп Ёмгіѓбе(); 

? #е1зе 

2 # 1Е аеЕ1теа(__5трс _) || аеЕ1теа (__ср1азр1а$) 

г. ехЕехгп ѕіғе © Ёгеаа (уоіа*, ѕіғе ё, ѕіғе б, ЕТЬЕ*); 
? ехбегп ѕіғе і Ёмгібсе (сопѕі уоіа*, ѕіғе б, ѕіле С, РТЬЕ*); 
? # е1зе /* пор _ 5ТрС _ || _ ср1авр1ав */ 

? ехбегп ѕіле і Егеаа(); 

? ехбегп ѕіғе б Ёмгібе(); 

? # епа1Е /* е1ѕе пої _5Трс__ || __ ср1авр1ав */ 

? #епаіғ 


Этот пример не содержит ошибок, но он демонстрирует, что подобные заголовоч- 
ные файлы (и программы) устроены слишком сложно и с трудом поддаются доработ- 
ке. Было бы легче использовать отдельный файл для каждого компилятора или среды. 
Конечно, пришлось бы работать сразу с множеством таких файлов (обеспечивая их 
поддержку и доработку), но каждый из них был бы самодостаточным и полностью 
приспособленным к своей системе. Это уменьшило бы вероятность таких ошибок, как 
включение функции ѕёгаир в среду строгого стандарта АМ$] С. 

Заголовочные файлы также могут “загрязнить” пространство имен, объявив функ- 
цию стем же именем, что и в программе. Например, наша функция для выдачи преду- 
преждающих сообщений, мергіпі ё, ранее называлась мргіпе#, но потом мы обна- 
ружили, что в некоторых средах функция с таким именем уже определена в заголовоч- 
ном файле ѕбаӢіо.Һ в ожидании нового стандарта АМ№5І С. Поэтому нам пришлось 
изменить имя функции, чтобы программа компилировалась без проблем во всех средах 
и в будущем ее не нужно было бы изменять. Если бы проблема состояла в ошибочной 
реализации, а не в нормальном изменении спецификации, мы бы могли обойти эту 
трудность, переопределив имя при включении заголовочного файла: 


2 /* некоторые версии ѕідіо используют мргіпіЁ, поэтому заменяем 
имя: */ 

? #дӢеҒіпе мрх1пЕЕ ѕбаіо мргіпсѓ 

р #1пс1аае <ѕіаіо.Һһ> 

? #опаеЕ мре1пЕЁ 

о 


/* далее код, использующий мргіпіЁ()... */ 


Этот код преобразует все вхождения мргіпе# в заголовочном файле в вызовы 
5СӢіо ирх1пЕЕ, чтобы они не пересекались с нашей версией. Теперь мы можем 
пользоваться нашей функцией мргіпе ғ, не изменяя ее имени. Цена, которую мы за 
это платим, — некоторая неуклюжесть кода и риск того, что компонуемая с нашей 
программой библиотека вызовет функцию мргіпе#, ожидая стандартную, а полу- 
чая нашу. В отношении одной функции, по-видимому, особенно волноваться 
не приходится, но некоторые системы создают такую путаницу в среде программи- 
рования, что для сохранения хорошего стиля приходится идти на крайние меры. 
Не забывайте комментировать, что именно делает конструкция, и не ухудшайте ее · 
работу добавлением условной компиляции. Если функция мргіпе# определяется в 
некоторых средах, следует предполагать, что то же самое происходит во всех. Тогда 


Раздел 8.3 Организация программы 231 


одного исправления будет достаточно и не придется сохранять множество операто- 
ров #1ЕаеЕ. Иногда лучше уклониться от конфликта, чем вступать в него (и это, 
несомненно, безопаснее). Именно так мы поступили, изменив имя функции на 
мергіпіғ. 

Даже если изо всех сил стараться придерживаться стандарта и работать в хорошо 
отлаженной среде, все равно бывает легко выйти за рамки, неявно предположив, что 
какое-то свойство имеет место всегда и везде. Например, в АМ$1 С определяется шесть 
сигналов, которые можно перехватить функцией ѕідпа1; в стандарте РОЅІХ таковых 
уже 19; в большинстве версий Опіх поддерживается 32 или больше сигналов. Если вы 
хотите воспользоваться нестандартным сигналом, то придется идти на компромисс 
между функциональностью и переносимостью, решая на ходу, что важнее. 

Существует много других стандартов, не являющихся частью определения языка. 
Среди них операционные системы, сетевые интерфейсы, графические интерфейсы 
ит.д. Некоторые работают в нескольких системах, как РОЅІХ; другие специфичны 
для одной системы, как многочисленные АР]-интерфейсы М1сгозой Міпӣомѕ. Здесь 
также применим все тот же совет. Ваши программы будут лучше переносимы, если 
выбрать широко распространенные, хорошо определенные стандарты и придержи- 
ваться только самых главных, общепринятых аспектов этих стандартов. 


8.3. Организация программы 


Существуют два основных подхода к переносимости, которые мы называем 
“объединением” и “пересечением”. “Объединение” подразумевает использование 
лучших черт каждой конкретной системы и соответственно организацию условной 
компиляции и инсталляции в зависимости от свойств среды. Получившийся код 
реализует объединение всех возможных сценариев и пользуется преимуществами 
всех систем. Недостатки этого подхода состоят в размере кода и сложности процесса 
установки программы, а также в запутанности исходного текста ввиду наличия 
большого количества операторов условной компиляции. 


Пользуйтесь только средствами, имеющимися в наличии везде. Мы рекоменду- 
ем именно подход “пересечения”: пользоваться только теми чертами и возможностями 
языка, которые существуют во всех системах, куда может переноситься код, и не поль- 
зоваться теми, которые имеются не везде. Опасность этого подхода состоит в том, что 
требование общедоступности возможностей может сузить круг систем, в которые 
может переноситься программа; также имеется риск падения быстродействия. 

Чтобы сравнить эти два подхода, рассмотрим несколько примеров, в которых 
используется “объединение”, и перепроектируем их под “пересечение”. Как мы по- 
кажем далее, код с “объединением” непереносим по самой своей структуре, несмотря 
на декларируемые этим подходом цели, тогда как код с “пересечением” не только 
переносим, но и устроен гораздо проще. 

Следующий небольшой пример представляет попытку приспособиться к среде, 
которая по какой-то причине не содержит стандартного заголовочного файла 
5911.8: 
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#1Е аеҒіпеа (ЅТЮС НЕАрЕВЅ) || деҒіпеа ( 11ВС) 
#іпс1џде <ѕіа1ір.һ> 
#е1ѕе 


ехіегп уоіа *та11ос (ипѕіспеа іпі); 
ехбегп уоіа *геа11ос (уоіа *, цпз1апеа 116); 
#епа1 Е 


хохол 0 


Эта мера предосторожности вполне приемлема, если используется время от време- 
ни, но не слишком часто. В связи с ней напрашивается также вопрос, сколько еще 
функций из зе а1 1Ъ придется декларировать в этом или аналогичном условно компи- 
лируемом коде. Например, если используются функции ма11ос и геа11ос, то пона- 
добится также и Егее. А что если тип чпз1апей іп? отличается по размеру от 
ѕіле Е, те. корректного типа аргументов та11ос и геа11ос? Более того, как нам 
узнать, определены ли константы 5Трс НЕАрЕрЅ или 1ІВС, причем определены ли 
они корректно? Откуда нам знать, не существует ли другого имени, которое может 
привести к конфликту или подмене имен в какой-либо системной среде? Любой код с 
условной компиляцией — наподобие этого — неполон в плане переносимости, потому 
что рано или поздно встретится система, не вписывающаяся в заранее определенные 
рамки, и операторы #і #деғ придется редактировать. Если бы удалось вовсе устранить 
условную компиляцию, мы бы решили проблему с последующей доработкой кода. 

Задача, которую решает этот код, вполне реальна. Так как же нам решить ее раз и 
навсегда? Мы бы предпочли предполагать, что существуют стандартные заголовоч- 
ные файлы; если это не так, то это проблема других людей. Но при отсутствии таких 
файлов будет проще включить в комплект поставки программы специальный заго- 
ловочный файл, в котором функции та11ос, хеа11ос и Ёгее определяются точно 
так же, как в АМ№І С. Этот файл можно включать в программу при любых условиях, 
вместо того чтобы лепить на код “заплатки” то тут, то там. Таким способом мы 
гарантируем, что необходимый интерфейс всегда будет в наличии. 


Избегайте условной компиляции. Условная компиляция с помощью операторов 
#1 ЕаеЕ и других подобных директив препроцессора трудна в управлении, посколь- 
ку таким образом информация рассеивается по всему исходному коду. 


#1ЕАаеЕ МАТТУЕ 

сһаг *аѕігіпад 
#е1ѕе 
#1ЕаеЕ МАС 

сһаг *аѕігіпад 
#е1ѕе 
#1ЕаеЕ роѕ 

сһаг *аѕігіп9 
#е1ѕе 

сһаг *аѕігіп9 
#епаіғ /* ?роѕ */ 
Непа1Е /* ?МАС */ 
Непа1Е /* ?МАТТУЕ */ 


"сопуегі АЅСІІ ёо паііуе сһагасіег зеё"; 


"сопуегі іо Мас ёехіЁі1е Ёогтаї"; 


и 


"сопуегі іо роѕ ёехі#і1е Ёогтаї"; 


"сопуегі ёо Оп1х ёехіҒі1е Ёогтаі"; 


хохол 


Этот отрывок лучше было бы структурировать с помощью #е11Е после каждого 
определения, вместо того чтобы нагромождать #епа1Е в самом конце. Однако 
настоящая проблема состоит в том, что, несмотря на намерение авторов, этот код 
исключительно плохо переносим, поскольку ведет себя по-разному в разных систе- 


Раздел 8.3 Организация программы 233 


мах и требует добавления нового #1Е4еЕ для каждой новой среды. Было бы проще 
ввести одну строку с более общим текстом, сделав код более простым, полностью 
переносимым и столь же информативным: 


сһаг *азбх1па = "сопуегі бо 1оса1 бех Еогтаё"; 


Здесь условная компиляция уже не нужна, поскольку строка останется одной и 
той же во всех системах. 

Смешение условной компиляции (выполняемой операторами #1Е4еЕ) с кон- 
трольными операторами программы очень неудачно, поскольку такой код трудно 
воспринимать. 


#1ЕпаеЕ ріІѕКЅҮЅ 
Бог (1=1; і <= тѕ9->ӣрдтѕд.тѕд Соба1; 1++) 
#епа1Е 
#1ЕаеЕ ріІѕкѕЅҮЅ 
і = даратѕдпо; 
1Е (1 <= пѕ9->аротѕ9.тѕд соба1) 
#епа1Е 


1Е (п59->дротѕд.тѕд Соёа1 == і) 
#1ЕпаеЕЁ ріІЅКЅҮЅ 
ргеак; /* больше сообщений не ожидается */ 
еще около 30 строк, также с условной компиляцией 
#епаіғѓ 


} 


Даже если условная компиляция кажется безвредной, ее часто можно заменить 
более безопасными методами. Например, директивы #і#де# часто используются 
для управления отладочным кодом: 

? #іғаеғ РЕВОС 


? ргіпеё(...); 
? #епаіғ 


хохол 


Однако столь же успешно можно использовать и обычный оператор ТЕ с посто- 
янным условием: 
епот { ОЕВОС = 0 }; 


і? (РЕВИС) { 
ргіпёЁ (...); 
} 


Если константа РЕВОС равна нулю, большинство компиляторов не сгенерируют 
никакого кода для блока в условном операторе, однако проверят синтаксис этого 
блока. А вот #1 Е4еЕ, наоборот, скроет возможные синтаксические ошибки, которые 
могут проявиться впоследствии при компиляции соответствующего блока. 

Иногда при условной компиляции исключаются очень большие блоки кода: 


#1ЕаеЁ поеаеЕ /* неопределенный символ */ 


#епа1Е 
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Или же: 
НЕО 
#епа1Е 


Однако условных конструкций можно вообще избежать, вместо этого подставляя 
по условию различные файлы во время компиляции. К этой теме мы вернемся в сле- 
дующем разделе. 

Если приходится модифицировать программу под новую среду, не начинайте с 
создания копии всей программы. Вместо этого попытайтесь адаптировать ориги- 
нальный код. Вероятно, потребуется внести изменения в основной массив кода, 
и если делать это с копией, то вскоре возникнут различные версии с сильными рас- 
хождениями. Насколько это возможно, следует держать у себя только один экземп- 
ляр исходного кода. Если обнаруживается, что необходимо изменить что-нибудь для 
приспособления кода к конкретной среде, найдите способ внести такие изменения, 
чтобы они работали везде. Измените внутренние интерфейсы, если это необходимо, 
однако сохраните код самосогласованным и избегайте директив #1ЕаеЕ. Это обес- 
печит переносимость кода в дальней перспективе, а не его узкую специализацию. 
Сузьте “пересечение”, а не расширяйте “объединение”. 

Мы уже высказались против условной компиляции и продемонстрировали неко- 
торые вызываемые ею проблемы. Однако мы еще не упомянули самую сложную из 
них: такой код практически невозможно тестировать. Одна директива #1ЕаеЕ пре- 
вращает одну программу в две, компилируемые отдельно. При этом трудно судить, 
все ли вариации одной программы были скомпилированы и протестированы. Если в 
один блок #1 Ёде? вносится изменение, оно же может понадобиться и в других, од- 
нако проверить его работу можно только в тех средах, в которых активизируются 
соответствующие блоки. Если аналогичное изменение необходимо внести в другие 
конфигурации, его нельзя протестировать. Если мы добавляем новый блок #1 ЕаеЕ, 
трудно изолировать данное изменение от других и определить, каким еще условиям 
необходимо удовлетворить, чтобы попасть в это место программы, и где еще может 
понадобиться устранение этой же проблемы. Наконец, если в коде какая-то часть 
опускается по условию, то компилятор просто ее не воспринимает. Эта часть может 
быть полной чепухой, но мы этого не узнаем до тех пор, пока какой-нибудь невезу- 
чий клиент не попытается скомпилировать ее в среде, где активизируется именно 
эта часть. Так, следующая программа компилируется, если определена константа 
_ МАС, и не компилируется в противном случае: 


#іҒдӢеғ МАС 

ргіпё# ("Тһіѕ іѕ Масіпёоѕћ\г"); 
#е1 зе 

Синтаксическая ошибка в других системах 
#епа1Е 


Итак, наши предпочтения состоят в том, чтобы пользоваться только общими чер- 
тами для всех сред. В этом случае можно скомпилировать и протестировать весь код. 
Если где-то имеется проблема с переносимостью, мы переписываем это место, вме- 
сто того чтобы добавлять условно компилируемые блоки. Следуя этим путем, мы 
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непрерывно улучшаем переносимость и качество программы в целом, вместо того 
чтобы неоправданно усложнять ее. 

Некоторые большие системы поставляются вместе со сценариями конфигуриро- 
вания, позволяющими подстроить код под конкретную локальную среду. В процессе 
компиляции этот сценарий анализирует свойства среды: местонахождение заголо- 
вочных файлов и библиотек, порядок байтов внутри машинных слов, размеры типов 
данных, известные некорректные реализации языков (а таких на удивление много) 
ит.д. Затем сценарий генерирует параметры конфигурации или файлы связей про- 
екта, обеспечивающие адаптацию программы к среде. Такие сценарии бывают длин- 
ными и сложными, представляют собой существенную часть дистрибутивного паке- 
та программы и требуют постоянного контроля для поддержания работоспособно- 
сти. Иногда применение подобных методов необходимо, но, вообще-то, чем более 
код переносим и чем меньше в нем директив #1Е4еЕ, тем проще и надежнее его 
конфигурирование и установка. 


Упражнение 8.1. Исследуйте вопрос о том, как ваш компилятор воспринимает 
код внутри следующего условного блока: 
сопѕі іпё ОЕВОС = 0; 
/* или епим { ОЕВОб = 0 }; */ 


/* или Е1па1 Боо1еап ПЕВОС = Ға1ѕе; */ 
1Е (РЕВОС) { 


} 


При каких обстоятельствах здесь проверяется синтаксис? Когда генерируется 
код? Если в вашем распоряжении имеется несколько компиляторов, как соотносятся 
результаты их работы? 


8.4. Изоляция 


Хотя нам всегда хотелось бы иметь один пакет файлов исходного кода, которые 
бы компилировались без всяких изменений во всех системах, этот идеал практиче- 
ски недостижим. Однако ошибкой было бы и рассеивание непереносимого кода по 
всей программе, а именно эту проблему создает условная компиляция. 


Локализуйте зависимость от системы в отдельных файлах. Если для разных 
систем требуется разный код, эти различия следует локализовать в отдельных фай- 
лах — по одному на каждую систему. Например, текстовый редактор Ѕат работает 
в Опіх, МіпдӢомѕ и еще нескольких операционных системах. Системные интерфейсы 
в этих средах отличаются очень существенно, однако большая часть кода программы 
Зат остается в них неизменной. Вариации, присущие конкретной среде, собраны 
водном файле; так, файл ип1х.с содержит интерфейсный код для систем (Опіх, 
ам1паомз .с — для систем МіпдӢомѕ. Эти файлы реализуют интерфейс с операци- 
онной системой и скрывают различия от остальных модулей. На самом деле редак- 
тор бат вообще написан для своей собственной виртуальной операционной систе- 
мы, переносимой в различные реальные системы путем дописывания двух сотен 
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строк на С, которые реализуют с полдесятка небольших, но непереносимых опера- 
ций с использованием местных системных вызовов. 

Графические среды упомянутых операционных систем практически не имеют 
между собой ничего общего. Программа Зат справляется с этой проблемой, имея 
собственную переносимую библиотеку для своей графики. Хотя разработка такой 
библиотеки требует гораздо больших усилий, чем подгонка кода под заданную сис- 
тему (например, код интерфейса с системой Х УЛпдо\ всего в два раза короче, чем 
вся остальная часть программы Ѕат), в дальней перспективе это оказывается выгод- 
нее. Имеется и побочная выгода — эта графическая библиотека сама по себе пред- 
ставляет ценность и уже использовалась отдельно для того, чтобы сделать перено- 
симыми несколько других программ. 

Зат — довольно старая программа; в настоящее время для целого ряда платформ 
уже существуют переносимые графические среды, такие как ОрепСТ,, Тс]/ТК и ]ауа. 
Написание кода с использованием их, а не своих собственных разработок позволит 
придать вашим программам более всеобъемлющий характер. 


Скрывайте зависимость от системы за интерфейсами. Для проведения чет- 
кой границы между переносимой и непереносимой частями кода очень удобно ис- 
пользовать механизмы абстрагирования. Хорошим примером могут служить биб- 
лиотеки ввода-вывода, существующие в большинстве языков программирования: 
они представляют внешнюю память в виде набора файлов, которые можно откры- 
вать и закрывать, считывать и записывать, не беспокоясь об их физическом местона- 
хождении или о структуре. Программы, придерживающиеся какого-либо подобного 
интерфейса, будут работать на любой платформе, который его поддерживает. 

Реализация программы бат — это еще один пример абстрагирования. Для файло- 
вой системы и графических операций определен интерфейс, и программа использует 
только его средства и возможности. Сам интерфейс опирается на те средства, которые 
имеются в конкретной операционной системе. Реализации этих интерфейсов могут 
очень сильно отличаться в разных системах, но программы, использующие сами ин- 
терфейсы, совершенно независимы и при переносе не требуют никаких изменений. 

Подход к переносимости в языке Јауа показывает, как далеко можно зайти в раз- 
витии этой идеи. Программа на ]ауа транслируется в последовательность операций 
“виртуальной машины”, т.е. имитатора реальной системы, который легко реализо- 
вать в любой конкретной операционной среде. Библиотеки ]ауа обеспечивают еди- 
нообразный доступ к средствам операционной среды, таким как графика, пользова- 
тельский интерфейс, сеть и т.д.; средства самих библиотек опираются на то, что име- 
ется в системах. Теоретически одну и ту же программу на ]ауа можно выполнить в 
любой среде без изменений (даже после ее трансляции). 


8.5. Обмен данными 


Текстовые данные легко переносятся из одной системы в другую, и это самый 
простой способ обмена информацией произвольного содержания между системами. 


Используйте текстовые форматы для обмена данными. Текст легко обраба- 
тывать самыми разными программами и способами. Например, если выходные дан- 
ные одной программы не вполне соответствуют требованиям другой, для которой 
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они должны служить входными данными, то для их исправления можно применить 
сценарий на языке А\К или Рег]. Для выбора или отбрасывания строк можно вос- 
пользоваться утилитой агер; более сложные изменения могут выполняться с помо- 
щью текстового редактора. Текстовые файлы также гораздо легче документировать, 
а иногда документирование вообще не нужно, поскольку люди и так могут их прочи- 
тать. С помощью комментария в текстовом файле можно указать, какая версия про- 
граммы нужна для его обработки. Например, первая строка Роѕ$сгірѓ-файла указы- 
вает его кодировку: 


%$!Р5-Ааоре-2.0 


Напротив, двоичные файлы требуют для своей обработки строго специализиро- 
ванных программ и редко могут использоваться совместно даже в одной системе. 
Существует ряд программ, которые преобразуют любые двоичные данные в текст 
для их передачи с меньшей вероятностью повреждения. Среди них — ріпһћех для 
систем Масіпќоѕћ, ицепсоае и цидесоае для Чщх, а также различные программы 
МТМЕ-кодирования для передачи двоичных данных в почтовых сообщениях. В гла- 
ве 9 демонстрируется семейство функций кодирования и декодирования двоичных 
данных в пакеты и из пакетов для пересылки между системами. Само разнообразие 
подобных программ уже говорит о проблемах, связанных с двоичными форматами. 

С обменом текстовыми данными связана одна старая, давно всем надоевшая про- 
блема: в ІВМ РС-совместимых системах для завершения строки используется пара 
символов “возврат каретки” (\г) и “перевод строки” (\п), в то время как в Опіх — 
только символ новой строки. “Возврат каретки” — это пережиток, оставшийся от до- 
потопного устройства под названием телетайп, в котором существовала операция 
возврата каретки (СК) для перемещения печатающего механизма на начало строки, 
а также отдельная операция перевода строки (Т.Е) для перемещения к началу сле- 
дующей строки. 

Даже при том, что в современных компьютерах нет никаких возвращаемых 
“кареток”, программы для РС все равно большей частью ожидают именно эту ком- 
бинацию (общеизвестную под названием СКІЕ, что произносится как “керлиф”) 
в конце каждой строки. Если возврата каретки нет, весь файл может быть воспринят 
как одна гигантская строка. Подсчет строк или символов может оказаться неверным 
или произвольно изменяться. Некоторые программы справляются с этой ситуацией 
корректно, однако большинство — нет. Системы для РС — не единственные винов- 
ники; из-за цепочки последовательных попыток поддержания обратной совместимо- 
сти некоторые современные стандарты сетевой связи, такие как НТТР, также 
используют комбинацию СВЕ для отделения строк друг от друга. 

Наш совет — пользоваться стандартным интерфейсом, который воспринимает 
комбинацию СВГЕ последовательно и согласованно в каждой конкретной системе. 
Так, на РС выполняется удаление символа \г при вводе и его возврат на место при 
выводе. В Опіх для отделения строк в файлах всегда используется символ \п, а не 
СВГЕ. Если необходимо часто переносить файлы с одних машин на другие, то про- 
сто необходимо иметь программу для автоматического преобразования текстовых 
форматов. 
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Упражнение 8.2. Напишите программу, которая бы удаляла лишние символы 
возврата каретки в файле. Напишите вторую программу, которая бы добавляла их 
путем замены всех символов конца строки на символы возврата каретки плюс такие 
же символы конца строки. Как протестировать эти программы? 


8.6. Порядок следования байтов 


Несмотря на вышеописанные недостатки, двоичные данные все-таки бывают не- 
обходимы. Они более компактны, их быстрее декодировать, и эти факторы часто де- 
лают их удобными для многих задач обработки компьютерной информации в сетях 
и т.п. Однако с двоичными данными связаны серьезные проблемы переносимости. 

По крайней мере одну проблему все-таки удалось решить окончательно: все со- 
временные системы основаны на 8-битовых байтах. Однако в различных системах 
объекты длиннее одного байта уже могут представляться по-разному, поэтому пола- 
гаться на их специфические свойства нельзя. Например, в коротком целом числе 
(зНохгЕ іпе, обычно 16 бит или 2 байта) младший байт может помещаться по 
меньшему адресу, чем старший (так называемый “остроконечный” принцип, “і0е- 
еп ап”), или по большему адресу (“тупоконечный” принцип, “Ьіе-епдіап”). Этот вы- 
бор довольно произволен, а некоторые системы даже поддерживают обе модели. 

Итак, хотя системы-“остроконечники” и системы-“тупоконечники” воспринима- 
ют память как последовательность слов в одном и том же порядке, они могут отсчи- 
тывать байты внутри слов по-разному. На приведенной ниже схеме четыре байта по 
рдресу 0 представляют шесзнадцатеризное целое число 0х11223344 на 


ГЕ) ГЕ) 


“тупоконечной машине и 0х44332211 — на “остроконечной”. 


12345678 


ВЕЕТ Г. 


Чтобы увидеть проблему в действии, протестируйте следующую программу: 


/* рубеогдег: выводит байты числа типа 1опд */ 
116 таіп (уоіа) 


ипз1отеа 1опд х; 

чпѕзідпеа сһаг *р; 

116 1; 

/* 11 22 33 44 => тупоконечник */ 

/* 44 33 22 11 => остроконечник */ 

/* х = 0х112233445566778801; для 64-бит.1опа */ 

х 0х1122334401; 

р = (чпѕідпеа сһаг *) &х; 

Ғор (і = 0; і < $12еоЕ (1оп9); 1++) 
ргіпё# ("%х ", *р++); 

ргіпё# ("\п"); 

геіигп 0; 
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ә 


В 32-разрядной “тупоконечной” системе на выходе получаем: 


11 22 33 44 


У” 


Однако в “остроконечной” системе результат будет таким: 
44 33 22 11 


На машине РОР-11 (это давно устаревшая 16-разрядная ЭВМ, все еще встре- 
чающаяся в виде встроенных контроллеров) получим следующее: 


22 11 44 33 


В системах с 64-битовым типом 1опа можно сделать константы побольше и 
получить аналогичный результат. 

Эта программа может показаться пустым развлечением, но это не так. Если необ- 
ходимо послать целое число по параллельному соединению шириной в один байт, 
например по сетевому кабелю, мы должны выбрать, какой байт посылать первым. 
Тут-то и возникает главный вопрос — выбор между “тупоконечниками” и 
“остроконечниками”. Другими словами, программа делает явным образом примерно 
то же, что следующий вызов делает неявно: 


Ғнгісе (&х, ѕілеоЁ (х), 1, зЕаоце); 


Рискованно записывать целое число типа іп? (а также зпогЕ или 1оп9) на 
одном компьютере, а затем считывать его тоже как 1п на другом. 
Пусть передающий компьютер записывает данные, используя такой код: 


опѕісдпеа зрогё х; 
Ғнгісе (&=Х, ѕілеоЁ (х), 1, зЕаоце); 


Принимающий компьютер считывает их этим кодом: 
опѕіспеа зрогё х; 


Ғгеаа (&х, ѕілеоЁ (х), 1, зіаіп); 


Если в двух системах порядок байтов отличается, значение х не сохранится. Если 
х вначале равно 0х1000, то прибыть оно может уже как 0х0010. 

Эту проблему часто решают условной компиляцией и перестановкой байтов, 
т.е. примерно так: 


? БѕҺог Хх; 

? Ғгеаа (&х, ѕілеоҒ (х), 1, ѕбаіп); 

? #1ЕаеЕ ВТС _ЕМОТАМ 

? /* перестановка байтов */ 

? х = ((х&0ХЕЕ) << 8) | ((х>>8) & ОХЕЕ); 
? #епа1Е 


Этот подход становится совсем неудобным, если нужно обмениваться многими 
двух- и четырехбайтовыми числами. На практике байты приходится постоянно пе- 
реставлять, поскольку они перемещаются с места на место. 

Уж если положение с типом ѕћоге настолько плохо, можете себе представить, 
что творится с более длинными типами данных, для которых возможно большее ко- 
личество перестановок. Добавьте сюда выравнивание переменных-элементов струк- 
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тур, дополнение членов до слов пустыми байтами, загадочный порядок байтов на 
старых машинах, и проблема приобретет совершенно неразрешимый характер. 


Используйте фиксированный порядок байтов для обмена данными. И все- 
таки решение существует. Запишите байты в каноническом порядке, используя 
переносимый код: 

11051апеЯ звогё х; 


рчёсһаг (х >> 8); /* запись старшего байта */ 
рчёсһаг (х & ОхЕЕ); /* запись младшего байта */ 


Затем считайте их обратно по одному и снова соберите в единое целое: 


опѕіспеа ѕһогі х; 
х = десһаг() << 8; /* чтение старшего байта */ 
х |= дебсһаг() & ОХГЕ; /* чтение младшего байта */ 


Этот подход обобщается и на структуры, если записывать их элементы в опреде- 
ленном порядке, по одному байту и без добавления заполнителей. Неважно, какой 
именно порядок байтов выбран; важно лишь единообразие. Единственное требование 
заключается в том, чтобы отправитель и получатель согласовали между собой порядок 
байтов при передаче и количество байтов в каждом объекте. В следующей главе будет 
продемонстрировано несколько функций для пакетирования абстрактных данных. 

Побайтовая обработка может показаться слишком затратной, но учитывая слож- 
ность операций ввода-вывода, делающих подобное пакетирование данных необхо- 
димым, экономия составляет целые минуты. Взять хотя бы систему Х Міпдож, в ко- 
торой клиент записывает данные в своем естественном порядке, а сервер должен 
распаковывать все, что ему присылает клиент. На стороне клиента таким образом 
можно сэкономить несколько байт, однако сервер становится более громоздким и 
сложным из-за необходимости обрабатывать несколько разных порядков байт (ведь 
могут существовать как “остроконечные”, так и “тупоконечные” клиенты). Затраты 
на разработку такого сложного серверного кода намного превзойдут объем экономии 
со стороны клиентов. Кроме того, это графическая среда, в которой дополнительные 
затраты на пакетирование байтов — ничто по сравнению с объемом графических 
операций, которые закодированы этими байтами. 

Система Х УЛ тдо\ запрашивает порядок байтов у клиента и требует от сервера 
обрабатывать любой из возможных. В противоположность ей, операционная система 
Р1ап 9 задает порядок для сообщений, поступающих на файловый (или графиче- 
ский) сервер, а сами данные кодируются в пакеты и декодируются переносимым ко- 
дом, как описано выше. На практике разница в быстродействии не заметна; по срав- 
нению с затратами на операции ввода-вывода пакетирование байтов не имеет ника- 
кого существенного веса. 

Язык Јауа поддерживает более высокий уровень абстрагирования, чем С или 
С++, так что в нем вопросы порядка байтов вообще скрыты от программиста. В биб- 
лиотеках имеется интерфейс 5ег1а112аЪ1е, который задает правила для пакети- 
рования элементов данных с целью обмена или пересылки. 

Однако в С или С++ всю работу приходится делать самостоятельно. Ключевым 
преимуществом побайтовой обработки является то, что проблема решается без ди- 
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ректив #1 Е4еЕ во всех системах, где байты содержат 8 бит. В следующей главе мы 
еще остановимся на этом вопросе. 

И все же лучшим решением часто является преобразование данных в текстовый 
формат, который абсолютно переносим (если не считать проблемы СВТ.Р) и не со- 
держит двусмысленности в представлении данных. Но это решение не абсолютно и 
годится не для всех случаев. Например, может играть роль время выполнения или 
затраты памяти, а некоторые данные, в частности вещественные с плавающей точ- 
кой, могут терять точность из-за округления при прохождении через функции 
ре1пЕЕ и зсапЕ. Если необходимо обмениваться точными вещественнозначными 
данными, обзаведитесь библиотекой ввода-вывода с хорошим форматированием. 
Такие библиотеки существуют, хотя и не всегда входят в состав стандартных сред. 
Особенно тяжело представить числа с плавающей точкой в переносимом двоичном 
виде, однако при тщательном форматировании их преобразование в текст решает 
эту проблему. 

Имеется одна небольшая проблема переносимости при использовании стандарт- 
ных функций по работе с двоичными файлами — такие файлы необходимо откры- 
вать в двоичном режиме. 

ЕТЬЕ *Ё1п; 
Е1п = Еореп(Ь1паку_Ё11е, "гЫ"); 
с = деёс(Ё1т); 


Если опустить 'Ь', в системах Отих обычно ничего не случается, а вот в Міпаомѕ 
первый же байт Сігі-7 (восьмеричный код 032, шестнадцатеричный 1А) во входном 
потоке прекратит чтение, как это случалось на наших глазах с программой работы со 
строками из главы 5. С другой стороны, использование двоичного режима для счи- 
тывания текстовых файлов приведет к сохранению символов \г во входных данных, 
а не к генерированию их на выходе. 


8.7. Переносимость и модернизация 


Одним из самых неприятных источников проблем с переносимостью является 
системное программное обеспечение, изменяющееся с течением времени. Измене- 
ния могут случиться в любом интерфейсе системы, вызывая совершенно необосно- 
ванную несовместимость между существующими версиями программ. 


Измените имя, если изменилась спецификация. Наш любимый (если можно 
так выразиться) пример — это изменение свойств команды есһо из системы (іх, 
первоначальное назначение которой состояло в выводе ее аргументов на экран: 

% есро ре11о, мог1а 


Һе11о, мог1а 
% 


Однако со временем команда есһо стала ключевым элементом многих команд- 
ных сценариев, и возникла настоятельная потребность генерировать форматирован- 
ные выходные данные. Поэтому свойства команды есһо изменили так, чтобы она 
интерпретировала свои аргументы почти как функция ргіпеғ: 
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% есһо 'ре11о\пмог1а' 
ре11о 

мог1а 

$ 


Эта новая возможность довольно полезна, однако она вызывает проблемы с пе- 
реносимостью любого сценария на командном языке, который не использует коман- 
ду есһо ни для чего больше, как только для отображения аргументов. Так, поведе- 
ние следующей команды теперь зависит от используемой версии есћо: 


% есһо $РАТН 


Если переменная случайно содержит символ обратной косой черты, что вполне 
может случиться в среде ПОЅ или У//шп4о\уз, этот символ будет интерпретироваться 
командой есһо. Разница будет похожа на различие между результатами выполне- 
ния операторов рх1пЕЁ (зЕх) и ргіпёё ("%5", ѕсг) в том случае, если строка 
зЕх содержит знак процента. 

Мы рассказали только малую толику из всей истории о команде есһо, но основ- 
ная проблема обрисовалась достаточно четко: изменения в системе могут привести к 
созданию различных версий программного обеспечения, которые намеренно ведут 
себя по-разному и при этом нечаянно создают проблемы с переносимостью. Обойти 
эти проблемы довольно трудно. В описанном случае все было бы гораздо проще, ес- 
ли бы новая версия команды еспо имела другое имя. 

Рассмотрим более непосредственный пример — команду зим системы Ох, 
выводящую на экран размер и контрольную сумму файла. Ее создали для контроля 
передачи информации: 


% зим Е11е 
52313 2 Ғі1е 


о, 


5 
% скопировать Е11е на другую машину обћегтасһіпе 


Се1пеё оёһегтасһіпе 


4» оо оо 


$ зим Ее 
52313 2 Е11е 


$ 


После пересылки файла контрольная сумма осталась той же, поэтому можно 
быть уверенными, что старая и новая копии идентичны. 

Системы росли и развивались, плодились новые их версии, и вот кто-то заметил, 
что алгоритм вычисления контрольной суммы далек от совершенства, так что сумму 
модифицировали и применили лучший алгоритм. Кто-то другой сделал то же на- 
блюдение и еще раз усовершенствовал алгоритм. В итоге сегодня мы имеем несколь- 
ко разных версий утилиты зим, и все они дают разные ответы. Мы скопировали 
один файл на ближайшие компьютеры, чтобы посмотреть результат работы зим: 


% зим Е11е 
52313 2 Е11е 


о, 


5 
% копировать Ёі1іе в систему тасһіпе2 


о, 


% копировать Ёі1е в систему тасһіпез 
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% Ее1пеЕ тасһіпе2 


аљ 


$ зим Е11е 

еаа0468 713 Ғі1е 
$ ёе1пеі тасһіпез 

> 

> вим Е11е 

62992 1 ғі1е 

> 

Итак, чем же вызвана разница между контрольными суммами: повреждением 
файла или различием версий эт? Возможно, и тем и другим. 

Получается, что команда зи является просто эталоном непереносимости: про- 
грамма, предназначавшаяся для контроля копирования файлов с одного компьютера 
на другой, стала совершенно бесполезной для своей исходной цели благодаря нали- 
чию множества разных версий. 

Исходная утилита эт вполне подходила для своей простой задачи, и ее неслож- 
ный алгоритм вычисления контрольной суммы оправдывал себя. “Усовершенство- 
вание”, возможно, и улучшило программу в некоторой степени, но не настолько, 
чтобы оправдать этим потерю совместимости. Проблема заключается не в самих 
усовершенствованиях, а в том, что несколько несовместимых программ фигурирует 
под одним именем. Внесенные изменения породили проблему с версиями, которая 
будет докучать пользователям еще многие годы. 


Поддерживайте совместимость с существующими программами и данными. 
Когда в свет выходит новая версия пользовательской программы наподобие тексто- 
вого редактора, обычно она способна читать файлы, созданные предыдущими, более 
старыми версиями. Это вполне естественно: в программу добавляются новые, ранее 
не ожидавшиеся возможности, и формат данных должен эволюционировать. Однако 
в новых версиях иногда забывают обеспечить пользователей средствами для записи 
файлов в предыдущих форматах. Пользователи новой версии, даже если они не 
пользуются ее новыми возможностями, не могут обмениваться файлами с теми, у 
кого есть только старая версия, поэтому все они под давлением обстоятельств выну- 
ждены переходить на новую версию. Это неприятно и достойно всеобщего осужде- 
ния, будь то технический просчет или специальная маркетинговая стратегия. 

Обратной совместимостью называется соответствие программы ее старой спе- 
цификации. Если вы собираетесь вносить в программу изменения, постарайтесь со- 
хранить полную поддержку старой версии и соответствующих данных. Хорошенько 
задокументируйте изменения и обеспечьте путь к отступлению, т.е. к восстановле- 
нию исходных функций. И что наиболее важно, взвесьте, является ли предложенное 
изменение действительно усовершенствованием, перевешивающим недостаток пло- 
хой переносимости, если таковая вносится данным изменением в программу. 
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8.8. Интернационализация 


Живя в Соединенных Штатах, легко забыть, что английский — не единственный 
язык в мире, АЗСИП — не единственный набор символов, $ — не единственный сим- 
вол денежной единицы, даты могут записываться начиная с дня, время может обо- 
значаться по 24-часовой шкале и т.д. Таким образом, еще один аспект широко пони- 
маемой переносимости заключается в возможности переноса программ через языко- 
вые и культурные барьеры. Эта тема практически необъятна, но здесь мы наметим 
только некоторые основные ее вопросы. 

Если программу необходимо приспособить для выполнения в любой среде без 
предположений о ее национально-культурном характере, то говорят об интернацио- 
нализации программы. С ней связано много проблем, от символьных наборов до ин- 
терпретации пиктограмм в графических интерфейсах. 


Не предполагайте, что используется кодировка АЅСІЇ. В большинстве стран 
мира используются более обширные, чем АЗСП, символьные наборы. Стандартные 
функции анализа символов, объявленные в файле сбуре.Һћ, обычно скрывают эти 
различия от программиста. Следующая проверка не зависит от конкретной кодировки: 


1Е (іѕа1рһа (с)) 


Кроме того, она работает и в тех языковых средах, где алфавитных символов 
может быть меньше или больше, чем в латинском наборе от а до 2, если программа 
скомпилирована в этой среде. Конечно, само название іѕа1рћа (“является ли алфа- 
витным”) достаточно красноречиво — в некоторых языках нет алфавитов, и о такой 
проверке вообще не идет речь. 

В большинстве европейских стран кодировка АЅСІІ расширена, поскольку она 
строго определяет коды только до 0х7Е (т.е. с использованием первых 7 бит), остав- 
ляя дополнительные символы для представления букв других языков. Кодировка 
Гаїіп-1, повсеместно используемая в Западной Европе, является надмножеством 
АЅСІІ, в котором байтовые коды от 80 до ЕЕ используются для разных символиче- 
ских знаков и букв с надстрочными или подстрочными знаками; например, Е7 пред- 
ставляет букву с. Английское слово роу (“мальчик, парень”) представляется в коди- 
ровке АЗСП или Іабіп-1 тремя байтами с шестнадцатеричными значениями 
62 6Е 79, тогда как француское слово дахгсоп (с тем же значением) представляется 
в кодировке Гап-1 байтами 67 61 72 Е7 6Е 6Е. В других языках определяются дру- 
гие знаки и символы, но все они не могут поместиться в 128 кодов, не используемых 
кодировкой АЗСП. Поэтому существует целый ряд конфликтующих стандартов, 
определяющих символы с кодами от 80 до ЕЕ. 

Некоторые языки вообще не помещаются в 8-битовое пространство кодировки. 
В основных восточноазиатских языках используются тысячи символов. Так, коди- 
ровки, используемые в Китае, Японии и Корее, основаны на 16-битовых представле- 
ниях. В результате чтение документа, написанного на одном языке, на компьютере, 
локализованном под другой язык, представляет собой серьезную проблему. Даже 
предполагая, что символы не искажаются при переносе документа, чтение китай- 
скоязычного документа на американском компьютере требует как минимум уста- 
новки специального программного обеспечения и шрифтов. Если же приходится 
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совместно пользоваться китайским, английским и русским языками, то возникаю- 
щие сложности просто неописуемы. 

Символьный набор Отисо4е представляет собой попытку исправить ситуацию, 
создав единую кодировку для всех языков мира. Кодировка Опісойе, совместимая с 
16-разрядным подмножеством стандарта 150 10646, основана на использовании 
16 битов для каждого символа, причем коды до О0ЕЕ включительно соответствуют 
кодировке Гайп-1. Таким образом, слово дагсоп в этой кодировке представляется 
16-битовыми кодами 0067 0061 0072 00Е7 006Е 006Е, кириллические символы 
занимают диапазон кодов от 0401 до 04ЕЕ, а иероглифической письменности отве- 
ден большой блок, начинающийся с 3000. Все распространенные языки, как и мно- 
жество менее распространенных, представлены в кодировке Опісойе, так что именно 
ею следует пользоваться при пересылке документов между разными странами или 
для хранения документов на нескольких языках. Кодировка Отсо4е становится все 
более популярной в Іһѓегпеї, а некоторые системы даже поддерживают ее как стан- 
дартный формат. Например, в языке Јауа именно Опісоде является естественным 
символьным форматом, используемым в текстовых строках. Операционные системы 
Р1ап 9 и ШЕгпо целиком основаны на Опісойе; это относится даже к именам файлов 
и пользователей. Система Мисгозой \УЛп4о\з$ поддерживает символьный набор 
Опісоае, но он не является в ней обязательным. Большинство приложений для 
У/іпаомѕ по-прежнему работает лучше всего с кодировкой АЗСП, однако на практи- 
ке происходит быстрая эволюция в сторону Отсо4е. 

Все же с кодировкой Опісоде связана и проблема: символы больше не помещают- 
ся в один байт, так что текст подвержен путанице с порядком байтов. Чтобы избе- 
жать этого, перед пересылкой между программами или по сети документы Опісоде 
обычно транслируются в потоково-байтовую кодировку под названием ОТЕ-8. 
Для передачи каждый 16-разрядный символ кодируется последовательностью из 1, 2 
или З байт. Символьный набор АЗСП занимает диапазон кодов от 00 до 7Е, причем 
все эти коды помещаются в один байт и именно так представляются в ОТЕ-8, что 
обеспечивает обратную совместимость этой кодировки с АЅСП. Значения от 80 
до ТЕЕ представляются двумя байтами, а 800 и выше — тремя байтами. Таким обра- 
зом, слово дагсой выглядит в кодировке ОТЕ-8 как последовательность байтов 
67 61 72 СЗ А7 6Е 6Е; код Опісоде Е7, т.е. символ с, представляется в ОТЕ-8 двумя 
байтами СЗ А7. 

Обратная совместимость кодировок ОТЕ-8 и АЗСП — великое благо, поскольку 
она позволяет программам, воспринимающим текст как неинтерпретируемый поток 
байтов, работать с Опісойе-текстом на любом языке. Мы испытали программу 
тагкоу из главы З на тексте в кодировке ОТЕ-8 на русском, греческом, японском и 
китайском языках, и всякий раз она выполнялась без проблем. Для европейских 
языков, в которых слова отделяются пробелами, символами табуляции или симво- 
лами конца строки с кодами АЅСП, на выходе получалась забавная словесная чепу- 
ха, как и ожидалось. Для других языков неплохо было бы изменить правила разбие- 
ния строк на слова, чтобы получить выходные данные, более соответствующие ис- 
ходному предназначению программы. 
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Языки С и С++ поддерживают “расширенные символы”, представляющие собой 
16-разрядные или более длинные целые числа, а также несколько вспомогательных 
функций для обработки символов Отсо4е или другого большого символьного набо- 
ра. Литералы, состоящие из расширенных символов, записываются так: Ь"...". 
Увы, с ними связаны дополнительные проблемы переносимости: программу с лите- 
ральными константами из расширенных символов можно прочитать только на дис- 
плее, поддерживающем этот набор. 

Поскольку для согласованной передачи из одной системы в другую символы 
приходится конвертировать в байтовые потоки (например, ОТЕ-8), в языке С есть 
функции для преобразования расширенных символов в байт-коды и наоборот. 
Но каково именно это преобразование? Правила интерпретации символьного набора 
и определение их перекодировки в поток байтов спрятаны в библиотеках, и извлечь 
их оттуда не так-то просто — ситуация, мягко говоря, неудовлетворительная. Хоте- 
лось бы надеяться, что когда-нибудь в светлом будущем все окончательно примут к 
использованию единый символьный набор; однако более вероятный сценарий раз- 
вития событий состоит в том, что путаница, связанная с порядком байтов, еще долго 
будет терроризировать мир программирования. 


Не предполагайте использование английского языка. Разработчики интерфей- 
сов должны иметь в виду, что для выражения одной и той же мысли в разных языках 
используется самое разное количество символов, поэтому в массивах и на экране 
должно быть предусмотрено достаточно пространства для этого. 

Возьмем, например, сообщения об ошибках. Как минимум, в них не должен упот- 
ребляться сленг и какие бы то ни было выражения из профессионального арго, понят- 
ные только избранным. Такие сообщения следует с самого начала формулировать про- 
стым, понятным языком. Распространенный подход — это собрать текст всех сообще- 
ний в одном месте, чтобы при переводе на другой язык их можно было легко заменить. 

Имеется множество других культурных различий, например формат мм/дд/гг 
для дат, используемый только в Северной Америке. Если есть вероятность, что 
программа будет использоваться в другой стране, такую зависимость от культурных 
традиций следует минимизировать или вообще исключить. Пиктограммы в гра- 
фических интерфейсах также часто зависят от культурного контекста. Некоторые из 
них могут оказаться совершенно непонятными пользователям той среды, для 
которой предназначается программа, не говоря уже об остальных. 


8.9. Резюме 


Легко переносимый код — это идеал, за который стоит бороться, поскольку в против- 
ном случае очень много времени тратится на внесение изменений при переносе програм- 
мы из одной системы в другую или на поддержание работоспособности программы при 
эволюции ее системного окружения или ее самой. Однако переносимость не достается 
бесплатно. Она требует тщательного программирования и знания проблемных мест со- 
вместимости во всех системах, в которые планируется перенос программы. 

Были рассмотрены два подхода к переносимости: “объединение” и “пересечение”. 
“Объединение” подразумевает разработку таких программ, которые работают в каж- 
дой из намеченных систем благодаря тому, что в них включен весь необходимый для 
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этого код с использованием таких механизмов, как условная компиляция. Этот под- 
ход имеет множество недостатков: слишком большие объемы кода, нередко слишком 
высокая его сложность, трудность доработки и тестирования программ. 

“Пересечение” подразумевает написание как можно большей части кода таким 
образом, чтобы она работала без изменений в любой из систем. Системно-зависимые 
фрагменты, без которых не обойтись, инкапсулируются в отдельные файлы исход- 
ного кода, служащие интерфейсом между программой и конкретной операционной 
средой. Этот подход также имеет свои недостатки, среди которых — потенциальная 
потеря быстродействия и даже отдельных функциональных возможностей, но в 
дальней перспективе его преимущества окупают затраты. 


Дополнительная литература 


Существует много описаний языков программирования, но лишь немногие из них 
достаточно точны и полны, чтобы служить надежными справочниками. Авторы питают 
субъективное пристрастие к книге Вгіап Кегшевап, Реппіѕ ВКисЫе, Тле С Ртюртаттіпв 
Гаприаве (Ргепйсе На]ї, 1988), но иона не может служить заменой стандарту. Книга Зат 
Нагђіѕоп, Сиу еее, С: А Ве/етепсе Мапиаі (Ргеписе На]!, 1994), к этому моменту вы- 
шедшая в четвертом издании, содержит хорошие рекомендации по переносимости про- 
грамм на С. Официальные стандарты языков С и С++ можно получить от 150 
([тетайопа! Отапігайоп јоғ Чапаатйганоп — Международная организация по стандар- 
тизации). Ближайшим к стандарту описанием ]ауа можно считать книгу Јатеѕ Соз[пв, 
ВИ Јоу, Сиу Ѕѓееје, Тйе /аоа Гаприаре 5ресіћсайоп (АЧЧ1воп-\Уез]ву, 1996). 

Книга ВКісһ Ѕіеуепѕ, Адоапсей Рғортаттіпр т ше Отіх Епоіғоптепі (А4діѕоп- 
Ұ/еѕ]еу, 1992) рекомендуется для изучения всеми программистами, использующими 
Ошх. Она содержит обстоятельное изложение принципов переноса программ между 
различными вариантами Чшх. 

РОЅІХ (Рома БЕ Ореғанпр 8уѕіет Іпіегјасе — переносимый интерфейс операционных 
систем) представляет собой международный стандарт, определяющий команды и биб- 
лиотеки на базе Опіх. Он обеспечивает единую стандартную среду, переносимость ис- 
ходного кода приложений, а также единый интерфейс ввода-вывода, файловых систем и 
процессов. Этот стандарт описан в серии книг, опубликованных организацией ІЕЕЕ. 

Термины “тупоконечники” и “остроконечники” ввел Джонатан Свифт в 1726 г. в 
своих “Путешествиях Гулливера”. Статья Оаппу Соћеп, “Оп Вау \’агз апа а реа юг 
реасе”, ІЕЕЕ Сотршет, ОсюЪег 1981, представляет собой волшебную сказку о про- 
блемах порядка байтов. Именно в ней упомянутые термины впервые появляются в 
контексте вычислительной техники. 

Система Рап 9, разработанная в лабораториях Ве], сделала переносимость цен- 
тральным приоритетом разработчиков. Система компилируется из одного исходного 
кода, лишенного директив #1 Едет, на целом ряде процессоров. В ней повсеместно ис- 
пользуется символьный набор Опісоде. Последние версии программы Зат (впервые 
описанной в статье “Тре Техі ЕДког зап”, боате—Ргасйсе апа Ехрепепсе, 1987, 17, 
11, р. 813-845) также используют набор Опісойе и при этом работают в самых разных 
системах. Проблемы работы с 16-разрядными наборами наподобие Отисоде рассмат- 
риваются в статье Ко Ріке, Кеп Тһотрѕоп, “Нео М№огіа..”, Ргосеейтез о] фе Уиег 
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1993 ОЅЕМІХ Сопјетепсе, Зап Перо, 1993, р. 43-50. Кодировка ОТЕ-8 впервые появи- 
лась на свет именно в этой статье. Данная работа имеется на Мер-сайте проекта Р1ап 9 
при Вей Г.аЪз вместе с текущей версией программы Ѕат. 

Система ІпЃегпо, основанная на опыте проекта Р]ап 9, в некоторой степени анало- 
гична Јауа по принципам устройства. Она определяет виртуальную машину, кото- 
рую можно реализовать в любой реальной системе, предоставляет язык (Глюбо), 
транслируемый в инструкции виртуальной машины, и использует Опісоде в качест- 
ве своего базового символьного набора. Она также включает в себя виртуальную 
операционную систему, обеспечивающую переносимый интерфейс для целого ряда 
коммерческих систем. Ее описание можно найти в статье Ѕеап Пог\ага, КоБ Ріке, 
Юауіа [ео Ргеѕоёќо, Оеппіѕ М. ВисШе, Номага \У. Тискеу, РЫір У/ицегфойотв, 
“Тһе Іһѓегпо Орегайп8 Ѕуѕѓег”, Вей Гађѕ ТесйттсаЛоитай 1997, 2, 1. 


Системы обозначений 


Вероятно, из всех творений человека самое поразительное — это язык. 


Джайлз Литтон Стречи. “Словесность и поэзия” 
(Сие; [лноп 5іғасћеу, \Мог4$ апа Роеїгу) 


Именно правильный выбор языка главным образом определяет, насколько легко 
будет писать программу. Вот почему в арсенале программиста-практика должны 
быть не только языки общего назначения наподобие С и его производных, но также 
программные среды-оболочки, языки разработки сценариев и множество проблем- 
но-ориентированных языков. 

Сила правильно выбранной системы обозначений простирается далеко за преде- 
лы традиционного программирования в область специализированных задач. Так, 
с помощью регулярных выражений можно записывать компактные (хотя нередко и 
трудночитаемые) определения классов строк; язык НТМІ позволяет определять 
макеты интерактивных документов и внедрять в них программы на других языках, 
например ]ауабсире; язык РоѕЅсгірё дает возможность выразить целый документ, 
такой как эта книга, в виде программы типографского макета. Программы текстово- 
го редактирования и электронных таблиц часто содержат средства программирова- 
ния на таких языках, как \151а| Ваѕіс, для вычисления выражений, получения ин- 
формации или управления макетом документа. 

Если для выполнения самой рутинной работы приходится писать слишком много 
кода или не удается выразить ту или иную процедуру достаточно удобно, возможно, 
вы просто пользуетесь не тем языком. Если нужный язык еще не существует, вам 
выпадает прекрасная возможность создать его самостоятельно. Изобретение языка 
совсем не означает разработку нового ]ауа; часто решение неудобной задачи стано- 
вится вполне прозрачным после смены системы обозначений. Для примера возьмем 
строки формата в функциях семейства ргіпі#, представляющие собой компактный 
и выразительный способ управления выводом на экран различных значений. 

В этой главе мы поговорим о том, как изменение системы записи или обозначе- 
ний позволяет решать проблемы, и продемонстрируем, как можно реализовать свой 
собственный специализированный язык. Мы даже рассмотрим возможность разра- 
ботки такой программы, которая бы сама писала другую программу. Это доведенный 
до крайности случай использования альтернативной системы обозначений, который 
встречается чаще и при этом гораздо проще в реализации, чем думают многие про- 
граммисты. 
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9.1. Форматирование данных 


Всегда существует разрыв между тем, что мы хотим приказать компьютеру (“реши- 
ка мою проблему”), и тем, что от нас требуется приказать, чтобы работа была выполне- 
на. Чем меньше этот разрыв, тем лучше. Удачно выбранная система обозначений по- 
зволяет проще выразить то, чего мы хотим, и мешает сказать что-нибудь не то по 
ошибке. Иногда хорошие обозначения открывают новые перспективы и позволяют 
решать ранее неразрешимые задачи, или даже ведут к новым горизонтам знания. 

Существуют системы обозначений для узких областей специализации. Будем на- 
зывать их мини-языками. Они не только обеспечивают удобный интерфейс, но и по- 
могают в организации программ, которые их реализуют. Хорошим примером мини- 
языка являются управляющие строки функции ргіпі ё: 


рке1пЕЕЁ("%а %6.2Е %-10.105\п", і, Ё, 8); 


Каждый знак % в строке формата сигнализирует о том, что необходимо считать, 
проинтерпретировать и вывести очередной аргумент функции; после нескольких 
необязательных флагов и показателей ширины полей тип параметра указывается 
буквой. Эта запись компактна, интуитивно естественна и проста в составлении, а ее 
реализация не представляет особых трудностей. Альтернативы, принятые в С++ 
(1овегеам) и ]ауа (јауа.іо), несколько более неуклюжи, поскольку в них нет 
специальной системы обозначений. Правда, они расширяются до пользовательских 
типов данных и предлагают проверку соответствия типов. 

Некоторые нестандартные реализации ргіпе# позволяют добавлять новые пре- 
образования к встроенному набору. Это удобно, если у вас имеются другие типы 
данных, требующие форматирования при выводе. Например, компилятор мог бы 
использовать спецификацию %1 для номера строки и имени файла; в графической 
системе может применяться спецификация %Р для точки и %В для прямоугольника. 
В том же духе составлена и неудобочитаемая строка из букв и цифр для получения 
биржевых котировок, рассмотренная в главе 4. Это компактная запись для органи- 
зации биржевых данных. 

Подобные примеры можно составить также на С и С++. Предположим, нужно 
переслать пакеты смешанных данных различных типов из одной системы в другую. 
Как было сказано в главе 8, самое надежное решение — это преобразовать данные в 
текстовое представление. Однако для стандартного сетевого протокола формат ско- 
рее должен быть двоичным из соображений быстродействия или объема. Как же на- 
писать код для работы с пакетами так, чтобы он был переносимым, высокоэффек- 
тивным и простым в использовании? 

Чтобы конкретизировать наше изложение, представим себе задачу пересылки 
пакетов из 8-, 16- и 32-битовых элементов данных между системами. АМЗГ С требу- 
ет, чтобы в переменной типа сһаг всегда хранилось не менее 8 бит, в ѕћоге — 
не менее 16, ав 1опа — не менее 32. Именно этими типами мы будем пользоваться 
для представления наших данных. Типов пакетов будет много; так, тип 1 может со- 
держать однобайтовый спецификатор типа, двухбайтовый счетчик, однобайтовое 
кодовое значение и четырехбайтовый элемент данных: 
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Пакет типа 2 может содержать одно короткое слово данных (ѕһћог?) и два длин- 
ных (1опа): 


Один из подходов — это написать функции кодирования и декодирования 
для всех возможных типов пакетов: 


1пЕ раск буре1 (ипѕідпеа сһаг *БаЁ, ип51дпеа ѕһогі соипё, 
чпѕідпеа сһаг уа1, ипз1апеа 1опа ааѓа) 
{ 


ипѕідпеа сһаг *Ыр; 


рр = РЕ; 

*рр++ = 0х01; 

*рр++ = соцпе >> 8; 
*рр++ = соипб; 
*рр++ = уа; 

*рр++ = даба >> 24; 
*рр++ = даба >> 16; 
*рр++ = даба >> 8; 
*рр++ = ааба; 
геёигп рр - БЕ; 


} 


В реальном протоколе таких функций, представляющих всевозможные 
“вариации на тему”, были бы десятки. Эти процедуры можно упростить, используя 
макроопределения или функции для обработки элементарных типов данных 
(ѕћогЄ, І1опд и т.д.), но даже в этом случае такой повторяющийся код подвержен 
ошибкам, трудно читается и плохо поддается доработке. 

Присущая коду повторяемость наводит на мысль, что нам может помочь удачно 
выбранная система обозначений. Заимствуя идею у ргіпсё, можно определить ми- 
ни-язык, на котором каждый пакет будет описываться короткой строкой, полностью 
определяющей его структуру. Последовательные элементы пакета могут кодиро- 
ваться обозначением с для 8-битового символа, ѕ для 16-битового короткого целого 
(=ћогЄ) и 1 для 32-битового длинного целого (1опа). Например, представленный 
выше тип пакета 1, включая его начальный байт типа, можно описать строкой фор- 
мата сзс1. В этом случае можно написать одну функцию раск для создания пакетов 
любого типа. Данный пакет создавался бы следующим вызовом: 


раск (Би#, "сѕс1", 0х01, соцпі, уа1, даба); 


Поскольку наша строка формата содержит только спецификации данных, нет 
никакой необходимости в знаке %, используемом в ргіпбї. 

На практике информация, приведенная в начале пакета, обычно сообщает полу- 
чателю, как декодировать остальные данные. Мы предполагаем, что первый байт 
пакета определяет его организацию. Отправитель кодирует данные в этот формат и 
посылает их; получатель считывает пакет, извлекает первый байт и пользуется им 
для декодирования остальной информации. 
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Ниже приведена реализация функции раск, заполняющей буфер БЕ закодиро- 
ванным представлением ее аргументов, которое определяется заданным форматом. 
Мы сделали все значения беззнаковыми, в том числе и байты в буфере пакета, чтобы 
избежать проблем с расширением знака. Мы также воспользовались традиционными 
операторами куредеЕ для краткости объявлений: 


суреаеЕ ипѕідпеа сваг чисраг; 
суреаеЕ ипз1апеЯ зрохЕ изроге; 
суреаеЕ ипз1апея 1опа ц1опд; 


Подобно зру1пеЕ, ѕсгсру и другим схожим функциям, в раск подразумевает- 
ся, что буфер достаточно велик для хранения результата; ответственность за это 
целиком лежит на вызывающем модуле. Не предпринимается также никаких попы- 
ток проверить соответствие между строкой формата и списком аргументов. 


#1пс1а4е <зідӢага.һ> 


/* раск: пакетирует двоичные данные в Биё, возвращает длину */ 
іп раск (исһаг *БиЁ, сһаг *ЕшЁ, ...) 


уа 1іѕі агаз; 
сһаг *р; 
исрак *Ьр; 
изрогё 5; 
ц1оп9 1; 
рр = Ыриѓ; 
уа зсагі (араз, Ёт); 
Ғог (р = Ёт; *р != '\0'; р++) { 
ѕмієсһ (*р) { 
сазе 'с': /* сһаг */ 
*рр++ = уа ага (агдз, 116); 
ргеак; 
сазе '5': /* зһогі */ 
5 = уа ага (агдѕ, 116); 
*рр++ = з >> 8; 
*рр++ = 8; 
ргеак; 
сазе '1': /* 1опа */ 
1 = уа ага (агдѕ, ич1опа); 
*рр++ = 1 >> 24; 


*рр++ = 1 >> 16; 
*рр++ = 1 >> 8; 
*рр++ = 1; 
ргеак; 


аӢеҒаці1ёб: /* неопознанный символ типа */ 
уа епа (агаз); 
геіигп -1; 


} 


уа епа (агдз); 
гебигп рр - БЕ; 
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Функция раск использует заголовочный файл зЕЯаха .В более активно, чем это 
делала функция ерх1 пе Е (см. главу 4). Последовательные аргументы извлекаются с 
использованием макроса уа_аха, причем первый операнд является переменной 
типа уа_115Е, инициализированной путем вызова уа ѕбаге, а второй операнд — 
типом аргумента (вот почему уа_ага является макросом, а не функцией). После 
окончания обработки следует вызвать уа епа. Хотя спецификации 'с' и 'з' пред- 
ставляют аргументы типа сһаг и ѕћог соответственно, их необходимо извлекать в 
формате іпё, поскольку компилятор С автоматически расширяет аргументы типа 
сһаг и ѕћог до іп, если они представлены аргументом-многоточием. 

Каждая функция раск буре теперь становится тривиальной и содержит всего 
одну строку, формируя вызов раск на основе своих аргументов: 


/* раск буре1: создает пакет формата 1 */ 
1пЕ раск ёуре1 (исһаг *роиЁ, оѕһогі соцпё, исраг \уа1, џ1опд даба) 


{ 
} 


Для декодирования пакета можно сделать то же самое: вместо того чтобы писать 
‘отдельный код для каждого формата, можно вызывать одну и ту же функцию 
опраск с разными строками формата. Это позволяет сосредоточить преобразование 
в одном месте: 


гесигп расКк(раЁ, "сѕс1", 0х01, сочпЕ, \уа1, ааба); 


/* ипраск: декодирует элементы пакета риё, возвращает длину */ 
106 опраск (исһаг *раЁ, сһаг *Ёті, ...) 
{ 

уа 1ізі агаз; 

сһаг *р; 

цсрах *рр, *рс; 

иѕһог *рз; 


и1опа *рі; 

рр = ЬЫиѓ; 

уа зсагї (араз, ётё); 

Ғог (р = ЕщЕ; *р != '\0'; р++) { 


ѕмієсһ (*р) { 
сазе 'с': /* сһаг */ 
рс = уа агч (агаѕ, исһаг*); 
*рс = *рр++; 
ргеак; 
саѕе !'5': /* знохЕ */ 
рз = уа ага (агдѕ, чврогё*); 


*рѕ = *рр++ << 8; 
*рз |= *рр++; 
ргеак; 


сазе '1': /* 1опа */ 
р1 = уа ага (аүдѕ, ч1опа*); 


*р1 = *рр++ << 24; 
*р1 |= *рр++ << 16; 
*р1 |= *рр++ << 8; 
*р1 |= *Юр++; 
ргеак; 
ЧеЁаи1Е: /* неопознанный символ типа */ 


уа_еп@ (агаѕ); 
геёигп -1; 
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} 


уа_епа (агдз); 
тебагп рр - РЕ; 


} 


Как и зсапЕ, функция ипраск должна возвращать несколько значений в вызы- 
вающий модуль, поэтому ее аргументы — это указатели на переменные, в которые 
следует поместить результаты. Возвращаемое значение равно количеству байт в 
пакете; его можно использовать для контроля. 

Поскольку все значения не имеют знака и мы обходимся только стандартными 
размерами АМ№І С для типов данных, передача информации происходит в полно- 
стью совместимом режиме даже между системами с разными размерами типов 
ѕћогї и 1опа. Информация будет передана корректно при условии, что программа, 
использующая раск, не попытается пересылать в виде 1опч (к примеру) значение, 
не представляемое 32 битами. Фактически пересылаются младшие 32 бита этого 
значения. Если необходимо пересылать более длинные данные, придется определить 
еще один формат. 

Теперь уже легко написать функции декодирования данных из пакетов, исполь- 
зующие функцию ппраск: 


/* цпраск буре2: декодирует пакет типа 2 */ 
іп опраск ёуре2 (116 п, чсһаг *БаЕ) 
{ М 

осҺаг с; 

изроге соцпі; 

ц1опа м1, 02; 


1Е (опраск (Би, "сѕ11", &с, &соцпі, &9м1, &9м2) != п) 
геёигп -1; 
аззехе (с == 0х02); 


гесоүп ргосезз_буре2 (соипе, дм1, м2); 


} 


Для вызова функции ипраск ёуре2 вначале следует распознать, что перед нами 
пакет типа 2. Это подразумевает цикл приема пакетов наподобие следующего: 


мһі1е ((п = геайраскеї (песмогк, БаЕ, ВОЕЅ12)) > 0) { 
ѕмібсһ (Ьо [0]) { 
аеҒаџціѓї: 
ергіпё# ("раа раскеї буре 0х%х", Ыиғ [0]); 
ргеак; 
сазе 1: 
ипраск_суре1 (п, БаЕЁ); 
ргеак; 
сазе 2: 
цпраск буре2 (п, БчЕ); 
Ьгеак; 
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Подобный код может сильно разрастись. Более компактный метод состоит в том, 
чтобы определить таблицу указателей на функции декодирования с индексацией по 
типу: 

іп (*ипраскёп []) (116, исһаг *) = { 
цпраск ёурео, 
ипраск_суре1, 
цпраск _ёуре2, 


}: 


Каждая функция из таблицы анализирует пакет, проверяет результат и иниции- 
рует дальнейшие операции по обработке этого пакета. Наличие таблицы делает 
работу приемного модуля тривиальной: 


/* гесе1уе: считывает пакеты из сети, задает обработку */ 
уоіа гесеіуе (іп пеёмохгКкК) 


{ 
исһаг буре, БаЕ[ВОЕ5Т7]; 
106 п; 
мһі1е ((п = геаараскее (песмогк, БаЁ, ВОЕЅІ2)) > 0) { 
суре = Ыи# [0]; 
1Е (суре >= МЕБЕМ$ (ипраскЁп)) 
ергіпі# ("раа раскес буре 0х%х", буре); 
1Е ((*цпраскёп [ёуре]) (п, БаЕЁ) < 0) 
еру1пЕЕ ("рхобосо1 еггог, буре %х 1Іепдбһ %а", 
Суре, п) Й 


} 


Код для обработки отдельных пакетов компактен, сосредоточен в одном месте и 
легко поддается доработке. Приемный модуль достаточно независим от самого про- 
токола, устроен просто и работает быстро. 

Этот пример основан на реальном коде, предназначенном для коммерческого 
сетевого протокола. Как только автор осознал работоспособность этого подхода, сра- 
зу же несколько тысяч повторяющихся строк, сильно подверженных ошибкам, со- 
кратились до нескольких сотен строк аккуратного, легко дорабатываемого кода. 
Итак, выбор удачной системы обозначений позволил значительно упростить работу. 


Упражнение 9.1. Модифицируйте функции раск и џпраск для корректной 
передачи значений со знаком, даже между системами с разными длинами типов 
зВоге и 1опа. Как следует модифицировать строки формата, чтобы в них указыва- 
лись типы со знаком? Как можно протестировать это код, например, на правиль- 
ность передачи числа -1 с компьютера, на котором числа типа 1оп9 имеют длину 
32 бита, на компьютер с 64-разрядными числами этого типа? 


Упражнение 9.2. Доработайте функции раск и ипраск для работы со строками; 
один из вариантов — это включить длину строки данных в строку формата. 
Расширьте возможности этих функций так, чтобы они могли работать с повторяю- 
щимися элементами посредством счетчика. Как это связано с кодированием строк? 


Упражнение 9.3. Таблица указателей на функции в программе на С очень близка 
по своей идее к механизму виртуальных функций С++. Перепишите раск, ипраск и 
гесе1уе на С++ так, чтобы воспользоваться этим удобным средством. 
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Упражнение 9.4. Напишите аналог функции ргіпёї в виде программы с интер- 
фейсом командной строки, которая выводит второй и последующие аргументы в 
формате, задаваемом первым аргументом. В некоторых средах программирования 
такая возможность уже существует как встроенная. 


Упражнение 9.5. Напишите функцию для реализации спецификаций формата, 
имеющихся в программах электронных таблиц или классе Рес1та1Еохгтае языка 
Таха. Эти спецификации служат для отображения чисел по шаблонам, указывающим 
обязательные и необязательные цифры, местоположение десятичной точки и запя- 
тых, и тд. Ниже продемонстрирован этот формат: 


НН, #НО.00 


Приведенный формат задает число с двумя десятичными позициями, как мини- 
мум одной цифрой слева от десятичной точки, запятой после числа тысяч и запол- 
нителем вплоть до количества десятков тысяч. В этом формате число 12345.67 пред- 
ставляется как 12,345.67, а .4 — в виде 0.40 (если подставить знаки под- 
черкивания вместо пробелов). Чтобы получить точную спецификацию, изучите 
определение класса Рес1та1Гогтае или описание программы работы с электрон- 
ными таблицами. 


9.2. Регулярные выражения 


Спецификации формата для функций раск и опраск образуют очень простую 
систему обозначений для определения состава сетевых пакетов. Наша следующая 
тема — несколько более сложная, но и намного более выразительная система обозна- 
чений под названием регулярные выражения, служащие для задания текстовых об- 
разцов и шаблонов. Регулярные выражения уже использовались в нашей книге вре- 
мя от времени без строгого определения; однако они достаточно знакомы многим и 
понятны без разъяснений. Хотя регулярные выражения очень распространены в 
среде программирования Чщх, в других системах они используются не так часто. 
В этом разделе будут продемонстрированы некоторые из их богатых возможностей. 
На тот случай, если у вас под рукой нет библиотеки для работы с регулярными вы- 
ражениями, будет показана также ее рудиментарная реализация. 

Существует несколько разновидностей регулярных выражений, однако по сути 
они все одинаковы. Это способы описания образцов текста, состоящие из литераль- 
ных символов, а также условных знаков для повторений, альтернатив и определен- 
ных классов символов наподобие букв или цифр. Один из известных примеров — так 
называемые символы подстановки, используемые в командных строках или оболоч- 
ках для обозначения групп имен файлов. Обычно звездочка (*) означает “любая 
строка символов”. Возьмем следующую команду: 


С:\> Яае1 *.ехе 
В ней используется шаблон, который соответствует всем файлам с произвольны- 


ми именами и расширением .ехе. Как это часто бывает, подробности реализации 
варьируются от системы к системе и даже от программы к программе. 
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Хотя причуды различных программ и систем заставляют думать, что регулярные 
выражения — это нестандартное проблемно-ориентированное средство, на самом 
деле это язык с формализованной грамматикой и точной семантикой для каждого 
высказывания данного языка. Более того, при хорошей реализации они могут рабо- 
тать очень быстро, поскольку сочетание строгой теории и инженерной практики 
обычно дает отличные результаты. Это пример преимуществ специализированных 
алгоритмов, на которые мы намекали в главе 2. 

Регулярное выражение — это последовательность символов, определяющая на- 
бор строк, который должен ему удовлетворять. Большинство символов выражения 
являются просто символами и ничем больше, так что регулярное выражение арс 
обозначает только эту строку, где бы она не встречалась. Кроме того, существует ряд 
мета-символов, обозначающих повторение, группировку или позиционирование. 
В стандартных регулярных выражениях Чшх символ ^ обозначает начало строки, 
а $ — ее конец, так что ^х соответствует символу х только в начале строки, х$ — 
в конце строки, ^х$ — в строке изединственного символа х,а ^$ — в пустой строке. 

Символ точки обозначает произвольный символ, так что шаблон х. у соответст- 
вует строкам хау, х2у ит.д., но не ху или хару, а ^.$ соответствует строке с един- 
ственным произвольным символом. 

Набор символов в квадратных скобках соответствует любому одному из них, 
т.е. запись [0123456789] обозначает одну произвольную цифру; эту строку можно 
сократить до [0-9]. 

Эти элементарные “кирпичики” можно комбинировать с помощью круглых ско- 
бок для группировки, знака | для выбора между альтернативами, * для выбора ни 
одного или любого количества вхождений, + для поиска одного или нескольких 
вхождений, а также ? для ни одного или одного вхождений. Наконец, обратная косая 
черта используется как префикс перед мета-символами, чтобы передать их букваль- 
но, без специального значения; поэтому \* является литералом, а \\ — литеральной 
обратной косой чертой. 

Наиболее известная программа для работы с регулярными выражениями — 
это утилита агер, которая уже неоднократно упоминалась ранее. Это образцовый 
пример ценности хорошей системы обозначений. Программа применяет заданное 
регулярное выражение к каждой строке своих входных файлов и выводит те строки, 
которые соответствуют выражению. Эта простая операция в сочетании с мощью 
регулярных выражений позволяет решать множество повседневных задач. В сле- 
дующих примерах просим заметить, что синтаксис регулярных выражений, исполь- 
зуемых в качестве аргумента агер, отличается от символов подстановки, задающих 
наборы файлов. Это различие отражает разные способы использования. Итак: 

Какие из файлов исходного кода используют класс Ведехр? 


$ агер Ведехр *.јауа 
Какие файлы содержат его реализацию? 
% агер 'с1аѕѕ.*Ведехр'! *.јауа 
Когда было сохранено почтовое сообщение от Боба? 


= дгер '^Егот:.* БоБ@' таі1/* 


258 Системы обозначений Глава 9 


Сколько непустых строк исходного кода содержит программа? 


= агер '.' *.с++ | мс 


Имея ключи для вывода номеров найденных строк, подсчета совпадений, игно- 
рирования регистра символов, обращения цели поиска (т.е. поиска строк, не удовле- 
творяющих заданному выражению) и других вариантов реализации основной идеи, 
программа агер используется так широко, что давно стала классическим инстру- 
ментом программирования пользовательских командных сценариев. 

К сожалению, программа агер или ее эквивалент имеется не в каждой операци- 
онной среде. В некоторых системах есть библиотеки для работы с регулярными вы- 
ражениями, обычно гедех или гедехр, которыми можно пользоваться при написа- 
нии программы, аналогичной агер. Если же нет ни того ни другого, можно само- 
стоятельно реализовать скромное подмножество полного языка регулярных 
выражений. Здесь мы представим реализацию регулярных выражений, а затем и 
аналога программы агер. Для простоты учтем только мета-символы ^ $ ., атакже *, 
который обозначает повторение одной предыдущей точки или литерального симво- 
ла. Это подмножество поддерживает весьма значительную часть возможностей ре- 
гулярных выражений, тогда как программировать придется лишь очень малую часть 
от общего объема работы, необходимой для полной их реализации. 

Начнем с самой функции определения совпадений. Ее назначение — определить, 
соответствует ли текстовая строка заданному регулярному выражению. 


/* тассһ: ищет регулярное выражение в тексте */ 
106 табсВ(срахг *хедехр, сһаг *№ехі) 


1Е (үедехр[0] == '^') 
гесигп таёсһһеге (гедехр+1, Сехі) ; 
Чо { /* искать даже в пустой строке */ 
1Е (тассһһеге (гедехр, бехг)) 
геёигп 1; 
} мһі1е (*сехе++ != '\0'); 
гесоигп 0; 


} 


Если регулярное выражение начинается с символа ^, текст должен давать совпа- 
дение с остатком выражения. В противном случае идем по тексту, пользуясь функ- 
цией таёсҺһеге для поиска совпадений в произвольной позиции. Как только 
совпадение обнаружено, работа окончена. Отметим использование цикла до-мН11е: 
выражения могут давать совпадения с пустой строкой (например, $ дает совпадение 
с пустой строкой в ее конце, а . * подходит под любое количество символов, включая 
нуль), поэтому функцию тассћћеге необходимо вызывать, даже если текст пуст. 

Большую часть работы выполняет рекурсивная функция таёсћћеге: 


/* таёсһһеге: ищет выражение гедехр в начале текста бех */ 
106 тассһһеге (сһаг *гедехр, сһаг *№ехі) 


1Е (хечехр [0] == '\0') 
тебаен, 1: 
1Е (үедехр [1] == '*') 


гесигп тассһѕбаг (гедехр [0], гедехр+2, бехі); 
1Е (үедехр[0] == '$' && гедехр[1] == '\0') 
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тебигп *ёехі == '\0!; 

1Е (*бехі!='\0' && (гедехр[0]=='.' || хедехр [0] ==*Еехе) ) 
геёџгп таёсһһеге (хедехр+1, ёбехё+1); 

гесигп 0; 


Если регулярное выражение пусто, значит, достигнут конец и найдено совпаде- 
ние. Если выражение заканчивается на $, оно дает совпадение только в том случае, 
если текст тоже находится в конце. Если выражение начинается с точки, то оно дает 
совпадение с любым символом. В противном случае выражение начинается с про- 
стого символа, дающего совпадение в тексте только с самим собой. Поэтому символ 
^ или $ в середине регулярного выражение должен восприниматься как литерал, а 
не мета-символ. 

Обратите внимание, что функция таёсћћеге вызывает сама себя после провер- 
ки совпадения одного символа из шаблона и строки, поэтому глубина рекурсии мо- 
жет достигать по величине длины шаблона. 

Один хитрый случай имеет место тогда, когда выражение начинается с символа 
со звездочкой, например х*. Тогда вызывается таёсһзбаг с первым аргументом в 
виде операнда звездочки (х) и последующими в виде образца, следующего за звез- 
дочкой и текстом: І 


/* таёсһѕбаг: ищет с*гедехр в начале текста */ 
106 таёсһѕбаг (іп с, сһаг *хедехр, сһаг *ЕехЕ) 


Чо { /* символ * соответствует любому количеству вхождений */ 
1Е (таёсһһеге (хедехр, %ехёЕ)) 
гесигүп 1; 
} мћі1е (*№сехб != '\0' && (*вехе++ == с || с == '.')); 
тебигп 0; 


} 


Здесь снова используется цикл до-мһі1е, запускаемый условием, что регуляр- 
ное выражение х* может давать совпадения с нулевым количеством символов. 
В цикле проверяется, соответствует ли текст оставшейся части выражения. Для это- 
го анализируется каждая позиция в тексте, пока первый символ соответствует опе- 
ранду звездочки. 

Это весьма незамысловатый алгоритм, но он работает, и его объем из менее чем 
30 строк кода показывает, что для реализации регулярных выражений нет нужды 
прибегать к сверхсложной технике программирования. 

Вскоре мы представим некоторые новые идеи для расширения возможностей 
кода. Пока же напишем версию программы агер, использующую функцию тмаЕсв. 
Вот главный ее модуль: 

/* агер таіп: ищет регулярное выражение в файле */ 
116 ма1п(1пЕ агас, срахг *ага\[]) 


{ 
116 і, птаёсһ; 
ЕТЬЕ *Ғ; 
ѕеіргодпате ("гер"); 
1Е (ахкас < 2) 
ергіпесї ("цѕаде: ачхер гедехр [Е11е ...]"); 
птпаёсһ = 0; 
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1Е (аүдс == 2) 
1Е (агер(акау[1], зеа1и, МО) ) 
птаёсһ++; 
} е1зе { 
Ғор (і = 2; і < акас; 1++) { 
Е = Ғореп (арду [1], "г"); 
ТЕ (Е == МОШ) { 
мерх1пЕЕЁ ("сап'6 ореп %5:", ахкау[1]); 
сопЕ1пце; 


1Е (агер (аүду [1], Ё, аүдс>3 ? аүду[і] : МОШЬ) > 0) 
птаёсһ++; 
Ес1озе (Ё); 


} 
} 
геіџгп птаєсһ == 0; 


} 


Обычно программы на С возвращают нуль в случае успеха и ненулевое значение 
в случае неудачи. Для нашей программы чгхер, как и для ее стандартной 
Опіх-версии, успехом является нахождение совпадающих строк, поэтому она воз- 
вращает о, если таковые имеются, 1, если нет, и 2 (через ергіпсё), если произошла 
ошибка. Эти значения можно проанализировать другой программой, например 
командным сценарием. 

Функция гер считывает один файл, вызывая функцию таєсһ для каждой 
его строки: 


/* агер: ищет выражение гедехр в файле Ё11е */ 
іп агер (сһаг *гедехр, ЕТЬЕ *Ё, срахг *паще) 


1106 п, пиабср; 
сһаг РаЕ [ВОЕЅІ2]; 
птаёсһ = 0; 


мћі1е (Ёдесѕ (ц, з12еоЁ БаЕ, ЕЁ) != №0) { 

п = эбу1еп (ри); 
1Е (п > 0 && БЕ[-1] == '\п') 

БаЕЁ [а-1] = '\0'; 
1Е (юмасһ (гедехр, Ьоғ)) { 

птаёсһ++; 

1ЁЕ (пате != М№МОІ1) 

ргіпС# ("%5:", папе); 


ргіпс# ("%5\п", БаЕЁ); 


} 


геіџгп птаєсһ; 


} 


Главный модуль не завершает выполнение, если не удается открыть файл. 
Этот путь был выбран потому, что пользователи нередко пишут нечто вроде этого: 


%$ дгер Һегро1һоде *.* 
Затем оказывается, что один или несколько файлов в каталоге не открывается. 


Для агер лучше продолжить работу, сообщив об ошибке, чем сдаться и заставить 
пользователя набирать список файлов вручную. Заметьте также, что агер выводит 
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имя файла и соответствующую строку, однако подавляет вывод имени, если чтение 
выполняется из стандартного потока ввода или одного файла. Это может показаться 
странным, но на самом деле отражает устоявшуюся практику, обоснованную опы- 
том. Если задан только один источник, задача агер обычно состоит в выборке строк, 
и имя файла было бы лишним среди результатов. А вот если программа разыскивает 
строки во многих файлах сразу, то задача чаще всего заключается в том, чтобы найти 
все вхождения определенной конструкции, и имена файлов являются ценной 
информацией. Сравните результаты двух команд: 


5 вігіпдѕ пагкоу.ехе | гер '005 пое! 


$ дгер дгаптег сһарбег* .іхС 


Именно эти черты вместе со многими другими делают программу агер столь по- 
пулярной и демонстрируют, что удачный выбор системы обозначений в сочетании с 
эргономическим подходом к делу позволяют создать естественный, удобный и мощ- 
ный инструмент. 

Наша реализация функции таєсћһ возвращает управление, как только находит 
совпадение. Для программы гер это приемлемое правило, заданное по умолчанию. 
Однако для реализации, например, операции подстановки (“найти и заменить”) в 
текстовом редакторе больше подходит алгоритм поиска самого левого и самого длин- 
ного совпадения. Например, в тексте "ааааа" регулярное выражение а* дает совпа- 
дение с нулевой строкой уже в начале, однако более естественно было бы найти все 
пять букв а. Чтобы функция тассћ находила самую левую и самую длинную стро- 
ку-соответствие, функцию таесВзеах следовало бы переписать: вместо перебора 
всех символов слева направо она должна перепрыгивать через самую длинную стро- 
ку, дающую совпадение с операндом звездочки, а затем возвращаться, если остаток 
строки не соответствует остатку заданного выражения. Другими словами, функция 
должна работать справа налево. Ниже приведена версия тассһѕсаг, выполняющая 
поиск самого левого и самого длинного соответствия. 


/* паёсһѕбаг: поиск по длинному левому совпадению с*гедехр */ 
1706 таёсһѕбаг (іп с, сһаг *гедехр, сһаг *іехі) 


{ 
сҺһаг *(; 
Ғор (Е = Бех; * != '\0' && (*Е == || е == '.'); Е++) 
до { /* * нуль или больше соответствий */ 
1Е (табсЬБеге (гедехр, +)) 
гесигп 1; 
} мһі1е (6-- > бехі); 
гесцгп 0; 


} 


Неважно, какое именно соответствие находит программа агер, поскольку она 
просто проверяет наличие такового и выводит всю строку. Раз функция с поиском 
самого длинного соответствия слева делает лишнюю работу, для программы хер 
она не нужна, хотя для операции поиска и замены является очень важной. 
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Наша реализация агер вполне конкурентоспособна по сравнению с системной 
версией, причем по любым поддерживаемым регулярным выражениям. Существуют 
случаи, вызывающие экспоненциальный рост затрат времени, например, поиск вы- 
ражения а*а*а*а*а*Ъ в тексте ааааааааас. Однако экспоненциальная зависи- 
мость присутствует и в некоторых коммерческих реализациях. Один из вариантов 
агер в системе Отих под названием едгер основан на более изощренном алгоритме, 
который гарантирует линейную зависимость, избегая возврата назад, если частичное 
совпадение не дало результата. 

Как же заставить функцию таЕсН обрабатывать любые регулярные выражения? 
Пришлось бы учесть классы символов наподобие [а-2А-7] для поиска букв алфа- 
вита, возможность буквального употребления мета-символа (например, чтобы найти 
в тексте все точки), группировку с помощью скобок, выбор из альтернативных вари- 
антов (арс или аеғ). Первый шаг — это помочь функции таёсћ, скомпилировав 
образец в такое представление, которое было бы легче считывать. Слишком сложно 
и дорого анализировать класс символов каждый раз, когда берется очередной 
символ текста; более эффективный подход — использование предварительно обра- 
ботанного представления, основанного на битовых векторах. Чтобы обеспечить под- 
держку полного языка регулярных выражений со скобками и альтернативным вы- 
бором, реализацию пришлось бы сделать намного сложнее. Но тем не менее и в ней 
можно использовать некоторые приемы, о которых пойдет речь далее в этой главе. 


Упражнение 9.6. Сравните быстродействие функций шаесн и зЕтгвЕхк при 
анализе соответствия простой строки без мета-символов. 


Упражнение 9.7. Напишите нерекурсивную версию функции таёсһһеге и 
сравните ее быстродействие с рекурсивной версией. 


Упражнение 9.8. Добавьте к ахер некоторые ключи и опции. Среди самых попу- 
лярных — ключи -у для обращения смысла поиска, -і для игнорирования регистра 
алфавитных символов и -п для включения в выходные данные номеров строк. 
Как должны выводиться номера строк? Следует ли включать их в те же строки, что 
и найденный текст? 


Упражнение 9.9. Добавьте в функцию тмаЕесН поддержку операций + (одно или 
больше соответствий) и ? (нуль или больше соответствий). Так, выражение а+ЪЪ? 
соответствует строкам из одного или более а, за которым следует ни одного или 
больше Ъ. 


Упражнение 9.10. В текущей реализации функции таесй отключено специаль- 
ное значение символов ^ и $, если выражение не начинается с них или не заканчива- 
ется ими, а также символа *, если за ним немедленно не следует литеральный сим- 
вол или точка. Более привычный способ — это делать мета-символ буквальным, ста- 
вя перед ним обратную косую черту. Внесите исправления в функцию тас, чтобы 
она именно так воспринимала обратные косые черты. 


Упражнение 9.11. Добавьте в функцию таесй анализ классов символов. Класс 
символов дает совпадение, если найден хотя бы один из символов в квадратных 
скобках. Можно поступить еще удобнее, употребляя диапазоны, например, [а-2] 
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для нижнего регистра латинского алфавита или [^0-9] (с отрицанием) для поиска 
всех нецифровых символов. 


Упражнение 9.12. Измените функцию тассһЬ так, чтобы она использовала вер- 
сию тассһѕбаг с поиском длинных левых соответствий, а затем модифицируйте ее 
так, чтобы возвращались позиции символов в начале и в конце найденного текстово- 
го совпадения. С ее помощью напишите программу дгез, аналогичную агер, но вы- 
водящую все исходные строки после подстановки нового текста вместо того, кото- 
рый соответствует заданному образцу, например: 


$ сдгеѕ 'Һотоіоцѕіап' 'Һоюмооцѕіап' тіѕѕіоп.ѕіті 


Упражнение 9.13. Измените модули маесЪ и дгер так, чтобы они работали со 
строками в кодировке ОТЕ-8, состоящими из символов Итисоде. Поскольку ОТЕ-8 и 
Опісоде являются надмножествами кодировки АЗСП, это изменение поддерживает 
прямую (не обратную) совместимость. Как регулярные выражения, так и текст не- 
обходимо приспособить к кодировке ОТЕ-8. Как в этом случае реализовать анализ 
классов символов? 


Упражнение 9.14. Напишите программу автоматического тестирования регуляр- 
ных выражений, которая бы генерировала тестовые выражения и тестовые строки 
для поиска соответствий. Если это возможно, воспользуйтесь существующей биб- 
лиотекой, — возможно, и в ней найдутся ошибки. 


9.3. Программирование в командных 
оболочках 


Многие программы и утилиты структурно основаны на специализированном 
языке. Программа дгер — это всего лишь один пример из большого семейства про- 
грамм и оболочек, использующих регулярные выражения или другие языки для ре- 
шения задач программирования. 

Одним из первых подобных примеров был командный интерпретатор, или язык 
управления заданиями. Довольно рано возникла идея поместить часто используе- 
мые последовательности команд в файлы и выполнить экземпляр командного ин- 
терпретатора или оболочки с этим файлом в качестве входного. А оттуда уже оста- 
вался один шаг к добавлению параметров, условных конструкций, циклов, перемен- 
ных и всех прочих прелестей обычных языков программирования. Основная 
разница состояла в том, что тип данных был только один — строковый, и отдельные 
операторы в таких программах сами представляли собой вызовы программ, выпол- 
няющих интересные и сложные вычисления. Хотя программирование в командных 
оболочках вышло из моды, уступив таким альтернативам, как Рег| в системах с ко- 
мандной строкой или нажимание кнопок в графических средах, оно все еще остается 
эффективным способом сборки сложных утилит из более простых операций. 

Одной из программируемых командных оболочек со своим языком является 
Аук. Этот небольшой специализированный язык основан на обработке текстовых 
шаблонов. Его основная задача — выбор и преобразование данных из входного пото- 
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ка. А\К автоматически считывает входные файлы и разбивает каждую строку на по- 
ля под именами от $1 до $МЕ, где МЕ — количество полей в строке (см. главу 3). Пре- 
доставляя стандартные, отработанные средства для многих задач, этот язык позво- 
ляет быстро писать полезные подручные утилиты. Рассмотрим следующую закон- 
ченную программу на Ам: 


# эзр116.амК: вывести поток по одному слову в строке 
{ Еог (і = 1; і <= МЕ; 1++) ргіпё $1 } 


Она выводит “слова” каждой из входных строк по одному на строке экрана. Ниже 
приведена реализация утилиты Ете, которая заполняет строки выходного потока 
словами так, чтобы длина их не превышала 60 символов. Пустая строка соответству- 
ет разрыву абзаца. 


# Еме.амК: переформатирование в 60-символьные строки 
/./ {Бог (1=1; і <= МЕ; 1++) айдмога ($1) } # попЬ1апк 1іпе 
/^$/ { руіпЕ1іпе(); ргіпе "" } # Барк 1іпе 
ЕМО { рк1пЕ11пе() } 
Ғџпсбіоп аЯамока (м) { 
1Е (1епобһ (1іпе) + 1 + Іепдһ (м) > 60) 


ргіпё1іпе () 
1Е (1епоёһ (1іпе) == 0) 
Ііпе = м 
е1ѕе 
1іпе = Ііпе " "и 
Ғџпсбіоп ргіпё1іпе() { 


1Е (1епоёһ (1іпе) > 0) { 
ргіпё 1іпе 
1іпе = ин 


} 


Мы часто пользуемся программой ЕтЕ для переформатирования почтовых сооб- 
щений и других коротких документов. Мы также пользовались ею для форматиро- 
вания выходных потоков программ тагКоу (см. главу 3). 

Такие программируемые оболочки часто начинаются с мини-языков, разработан- 
ных для естественного выражения технических решений в узкоспециализированной 
области. Один из удачных примеров — это утилита еар для Ошх, используемая для 
набора математических формул. Ее входной язык почти совпадает с выражениями 


л : 
математиков при чтении формул вслух; например, Э записывается как рі оуег 2. 


В системе ТЕХ используется тот же принцип; в ней эта формула записывается в ви- 
де \р1 \оуег 2. Если для решаемой вами задачи существует естественная или 
близкая система обозначений и выражений, используйте или адаптируйте ее, — это 
лучше, чем начинать с нуля. 

Толчком к созданию А\К послужила программа, распознававшая аномальные 
данные в журналах-протоколах телефонных переговоров с помощью регулярных 
выражений. Однако в А\К были включены переменные, выражения, циклы и т.д., 
что сделало его настоящим языком программирования. Рег и Тс| с самого начала 
разрабатывались так, чтобы сочетать удобство и выразительность мини-языков с 


Раздел 9.3 Программирование в командных оболочках 265 


мощью настоящих языков программирования. Это действительно языки самого 
общего назначения, хотя чаще всего они используются для задач обработки текста. 

Обычно в отношении языков таких программируемых оболочек употребляют 
термин языки разработки сценариев (ѕспіріпр іІаприареѕ), поскольку они эволюцио- 
нировали из более ранних командных интерпретаторов, программируемость кото- 
рых ограничивалась выполнением последовательностей, или “сценариев”, состоя- 
щих из запусков разных программ. Языки разработки сценариев допускают самые 
разные творческие применения регулярных выражений — не только поиск соответ- 
ствий (распознавание наличия того или иного выражения в тексте), но также опре- 
деление того, какие области текста подвергать определенной обработке. Именно это 
выполняется в двух командах гедѕир (сокращение от герш/аг ехртеѕѕіоп зибзйиноп — 
“подстановка регулярных выражений”) в приведенной ниже программе на языке Тс]. 
Это некоторое обобщение программы, продемонстрированной нами в главе 4, кото- 
рая извлекала информацию о биржевых котировках; теперь же наша программа из- 
влекает и доставляет документ с ОКІ -адресом, указанным в первом аргументе. Пер- 
вая подстановка удаляет строку һер: //, если она присутствует; вторая заменяет 
первый символ / пустым местом, таким образом разбивая аргумент на два поля. 
Команда 1 1паех извлекает из строки поля (начиная с индекса 0). Текст, заключен- 
ный в квадратные скобки, выполняется как команда Тс! и заменяется получившимся 
в результате текстом; запись $х заменяется значением переменной х. 


# десцгі.іс1: извлекает документ с указанным ОВІ-адресом 

# входные данные: [ВЕЕр://]арс.аеЁ.сом[/адрес...] 

геазиь "ВЕЕр://" $акау "" арду ;# удалить ВЕЕр:// если есть 
гечзир "/" $ака\у " " аүду ;# заменить / пустым местом 
зеЕ зо [ѕоскес [11паех $акау 0] 80] ;# открыть соединение 
зеЕ а "/ [11п4ех $акау 1]" 


риёѕ $ѕо "СЕТ $а НТТР/1.0\п\п" ;# послать запрос 

Е]азВ $50 

мһі1е { [9ебѕ $50 1іпе] >= 0 && $111е != ""} {} ;# пропустить 
заголовок 


раез [хеаа $50] ;# считать и вывести ответ 


Обычно этот сценарий выдает большой объем выходных данных, значительная часть 
которого — теги НТМІ. в угловых скобках (< >). Рег| хорошо справляется с подстанов- 
кой в текстах, поэтому следующая наша утилита написана на этом языке с использовани- 
ем регулярных выражений и подстановок, позволяющих избавиться от тегов: 


# ипһет1.р1: удаляет теги НТМЬ 


мһі1е (<>) { # сбор данных в одну строку 
5356г .= $_; # сцеплением входных строк 
$56 =- 5/<[^]*>//9; # удаление <...> 
$86г =- 3/&пЬзр;/ /9; # замена &пЬзр; пустым местом 
$86Е =- 5/\5+/\п/9; # сжатие пустого пространства 


ргіпіё $56к; 


Этот пример невозможно понять, если не владеть языком Рей. Следующая кон- 
струкция подставляет строку гер1 вместо текста в зех, соответствующего 
(по принципу левого самого длинного) регулярному выражению гедехр: 


$3Ех =- ѕ/гедехр/гер1/9 
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Последнее д (сокращение от &/ова/) означает, что это нужно сделать для всех 
соответствий в строке, а не только для первого. Мета-символ \з — это сокращение 
для произвольного символа пустого пространства (пробела, табуляции, символа но- 
вой строки и т.п.); \п обозначает конец строки. Строка "&прѕр; " является симво- 
лом НТМІ (как те, что приведены в главе 2) и определяет неразрывный пробел. 

Соберем все это вместе и продемонстрируем нелепый, однако работающий 
ҰеЬ-браузер, реализованный в виде однострочного командного сценария: 


# Пер: получает М№ер-страницу и выводит текст, игнорируя НТМЬ 
десиг1.ёс1 $1 | опһбт1.р1 | ётё.амк 


Этот сценарий извлекает \!е-страницу, отбрасывает всю управляющую и фор- 
матную информацию, а затем переформатирует текст по своим собственным прави- 
лам. Это очень быстрый способ загрузить страницу текста с \!еБ-сайта. 

Обратите внимание, сколько разных языков мы привлекли для решения ком- 
плексной задачи (Тс|, Рег|, АмК), причем каждый из них особенно хорошо подходил 
для конкретной подзадачи. Регулярные выражения использовались в каждом из них. 
Секрет силы систем обозначений состоит как раз в том, чтобы найти удачную систе- 
му для каждой задачи. Язык Тсі особенно хорош для загрузки текстовой информа- 
ции по сети; Ре! и АмК удобно использовать для редактирования и форматирования 
текста, а регулярные выражения применяются для того, чтобы выбрать фрагменты 
текста для поиска и модификации. Все вместе эти языки гораздо мощнее, чем каж- 
дый из них по отдельности. Всегда целесообразно разбить целую задачу на части, 
если благодаря этому можно воспользоваться удачными системами обозначений для 
каждой части. 


9.4. Интерпретаторы, компиляторы 
и виртуальные машины 


Как программа проходит путь от исходного текста к исполняемому коду? Если 
язык достаточно прост (например, строка формата ргіпё# или простейшие 
регулярные выражения), можно выполнить программу прямо на ходу из исходного 
кода. Это легко и не требует промежуточных этапов. 

Существует взаимно обратная зависимость между временем подготовки к вы- 
полнению и временем самого выполнения. Если язык сложен, то желательно преоб- 
разовать исходный текст в удобное и эффективное внутреннее представление для 
последующего выполнения. На предварительную обработку исходного текста ухо- 
дит некоторое время, но оно окупается более быстрым выполнением. Программы, 
объединяющие преобразование и выполнение в один процесс, т.е. считывающие ис- 
ходный текст, переводящие его на внутренний язык и сразу выполняющие, называ- 
ются интерпретаторами. Языки А\К и Рег — интерпретируемые, как и многие 
другие языки для разработки сценариев или узкой специализации. 

Еще один вариант — это сгенерировать инструкции для определенного вида сис- 
темы, в которой программа предназначена работать. Это делают компиляторы. 
Такой процесс требует самой длительной предварительной подготовки, но зато дает 
самое быстрое выполнение в будущем. 
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Существуют и другие комбинации. Одну из них мы рассмотрим в этом разделе — 
это компиляция программы в набор инструкций искусственной системы 
(виртуальной машины), которую можно имитировать на любом реальном компьюте- 
ре. Виртуальная машина сочетает в себе многие преимущества как традиционной 
компиляции, так и интерпретирования. 

Если язык достаточно прост, то выделить в программе структуру и преобразовать 
ее во внутреннюю форму достаточно просто и не отнимает много времени. Но если 
язык содержит сложные средства — декларации, вложенные управляющие структу- 
ры, рекурсивно определенные операторы или выражения, операции с разным при- 
оритетом и т.п., — то синтаксический анализ кода и определение структуры кода 
становится нелегкой задачей. 

Синтаксические анализаторы часто пишутся с помощью автоматических генера- 
торов, еще называемых компиляторами компиляторов, например уасс или Ьрізоп. 
Такие программы преобразуют описание языка (его грамматику) в программу на С 
(как правило) или на С++, которая после компиляции уже может транслировать 
операторы языка во внутреннее представление. Генерирование синтаксических ана- 
лизаторов непосредственно из грамматик — это еще одна демонстрация эффектив- 
ности хорошей системы обозначений. 

Представление, создаваемое синтаксическим анализатором, обычно является 
деревом, внутренние узлы которого содержат операции, а листья — операнды. 
Например, после разбора оператора 


а = пах(Ь, с/2); 


возникает следующее синтаксическое дерево: 


аЗ 
Е" 
р / 
А 7 


Многие из алгоритмов работы с деревьями, описанные в главе 2, могут использо- 
ваться для построения и разбора синтаксических деревьев. 

После того как дерево построено, его обработку можно продолжить разными спо- 
собами. Самый прямой, используемый в АМК, состоит в том, чтобы непосредственно 
обойти дерево, выполняя вычисления в узлах по мере обхода. Упрощенную версию 
процедуры вычислений для условного языка целочисленных выражений можно 
написать, например, с применением концевого обхода: 


суреде? ѕёгисё Ѕбутрої бупро1; 
сурейеЁ зігисі Тгее Тгее; 


зЕкисЕ бушро1 { 
106 уа1ае; 
сһаү *пате; 


}; 


ЗЕГиСЕ Тгее { 


268 Системы обозначений Глава 9 


106 ор; /* код операции */ 
іпё уа1че; /* значение, если число */ 
Ѕутро1 *ѕупро1; /* Ѕутро1, если переменная */ 
Тгее *1еїЁі; 
Тгее *гіһ; 
у 
/* еуа1: версия 1: вычисление выражения на дереве */ 
іпё еуа1 (Ткее *®) 


іп еб, гідһ; 
ѕмієсһ (Е->ор) { 
сазе МОМВЕК: 
геіцгп ё->уаіце; 
сазе УАВІАВІЕ: 
геёцгп Ё->ѕутро1->уаіце; 
сазе АРрр: 
геіигп еуа1 (ё->1е#ё) + еуа1 (->гідһё) ; 
саѕе ОТУТОЕ: 
1еЕЕ = еуа1 (Е->1еЁі) ; 
гідһе = еуа1 (Ё->гідһ) ; 
1Е (үідһе == 0) 
ергіпёғ# ("Яіуіде %а ру его", 1еЕ®); 
гебигп 1еЁб / гісһ; 
саѕе МАХ: 
1еЕЕ = еуа1 (Е->1еЁ) ; 
1916 = еуа1 (+->гідһ); 
геогп 1еЁб>гідһі ? 1еЕЁ : гүідһ; 
саѕе АЗЗТСМ: 
Е ->1еЕЕ->зутро] ->уа1це = еуа1 (і->гідһі) ; 
геёицгп 6 ->1еЕе->зутро1 - >уаіце; 
До 
} 
} 


В первых блоках сазе вычисляются простые выражения типа констант и значе- 
ний, далее — арифметические выражения, а еще дальше рассматриваются специаль- 
ные случаи, условные конструкции и циклы. Для реализации управляющих струк- 
тур на дереве необходимо было бы разместить дополнительную информацию, кото- 
рая здесь не показана. 

Как и в функциях раск и опраск, можно заменить явный оператор ѕміёсћ 
таблицей указателей на функции. Отдельные операции будут примерно такими же, 
как и в операторе м1 св: 


/* аааор: возвращает сумму двух выражений на дереве */ 
106 адаор (Тгее *®) 


гесигп еуа1 (&->1еЕ®) + еуа1 (6 ->г1аре); 


} 


Таблица указателей на функции сопоставляет операции с функциями, которые 
ИХ ВЫПОЛНЯЮТ: 
епим { /* коды операций, Ткее.ор */ 


МОМВЕВ, 
УАВІАВІЕ, 
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АОО, 
ОТУТОЕ, 
ДЕД 
у? 
/* орёар: таблица функций для операций */ 
іп (*орбаь[]) (Ткее *) = { 
разНор, /* МИМВЕВ */ 
риѕһѕутор, /* УАВТАВЬЕ */ 
айдор, /* Арр */ 
дӢіуор, /* ОТУТЬОЕ */ 
бж... ж/ 
Е 
При вычислении по знаку операции в таблице разыскивается указатель на функ- 
цию, а затем эта функция вызывается. В данной версии рекурсивно вызываются и 
другие функции. 
/* еуа1: версия 2: вычисления на дереве по таблице операций */ 
іпё еуа1 (Тгее *Ё) 


{ 


геіогп (*орёар [.->ор]) (Е); 


Обе версии функции еуа1 — рекурсивные. Существуют способы избежать ре- 
курсии, в том числе искусный прием организации многопоточного кода, который 
делает стек вызовов совсем мелким. Самый аккуратный метод избавления от рекур- 
сии — это помещение функций в массив и его последовательный перебор с целью 
выполнения программы. Этот массив фактически является последовательностью 
инструкций, выполняемых небольшой специализированной виртуальной машиной. 

И все-таки для представления частично вычисленных значений нам нужен стек. 
Форма функции изменяется, но это изменение легко проследить. Фактически мы 
изобрели стековую машину, в которой инструкции являются маленькими функция- 
ми, а операнды помещаются в отдельный стек операндов. Это не настоящая машина, 
но программировать ее можно вполне реально, и она легко поддается реализации в 
виде интерпретатора. 

Вместо обхода дерева с целью вычислений на нем можно обходить его для гене- 
рирования массива функций, предназначенных для выполнения программы. Такой 
массив будет также содержать значения данных, используемых в инструкциях 
(например, констант и переменных-символов), так что тип элементов в массиве 
должен быть объединением (цпіоп): 


суреаеЕ ип1оп Соае Соае; 
ип1оп Соае 
уоіа (*ор) (\о1а); /* функция, если знак операции */ 
іпё уа1ае; /* значение, если число */ 
Ѕутро1ї *ѕутро1; /* бутро1, если переменная */ 
; 

Ниже приведена функция для генерирования указателей на функции и помеще- 
ния их в массив соае соответствующих объектов. Возвращаемое из депегасе зна- 
чение является не значением выражения — оно будет вычислено только при выпол- 
нении сгенерированного кода, — а индексом следующей генерируемой операции в 
массиве соае: 
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зи1ЕСН (Е->ор) { 
сазе МОМВЕКВ: 
соае [содер++] 
соде [содер++] 
гебагп содер; 
сазе УАВТАВЬЕ : 
соае [содер++] 
соае [содер++] 
гебагп соаер; 
сазе АРрр: 


/* епегаіе: генерирует инструкции при обходе дерева */ 
іп депегасе (1пЕ содер, Тгее * +) 


.ор = риѕћһор; 
.ма1це = &->уа14е; 


.ор = риѕћһѕутор; 
.ѕутрої = ё->ѕутро1; 


сойер = депегабе (сойер, ё->1еғі); 


содер = депегаѓе (соаер, 


соде [соаер++] 
геогп содер; 
саѕе ОТУТОЕ: 


сойер = депегабе (сойер, ё->1еЁі); 


содер = депегаѓе (соаер, 


соде [соаер++] 
гегигп содер; 
саѕе МАХ: 


Р 90 


} 
} 


Для оператора а 
щим образом: 


рчѕһѕутор 
у) 
разВзутор 
с 

рчѕћор 

2 

аіуор 
тахор 
ѕсогезѕупор 
а 


е->гідһҺе); 
.ор = айаор; 


Є->гіһіё) ; 
.ор = аіуор; 


Глава 9 


тах (Ь, с/2) сгенерированный код выглядел бы следую- 


Функции для реализации операций манипулируют стеком, извлекая операнды и 


помещая результаты. 


Интерпретатор представляет собой цикл с перебором счетчика инструкций по 


массиву указателей на функции: 


Соде содае [МСОПЕ] ; 
іп зіаск [МЅТАСК); 


1106 зѕбаскр; 


іпё рс; /* счетчик инструкций */ 


/* еуа1: версия 3: 


Е); 


*/ 
іп еуа1 (Тгее *0) 
рс = чепегаее (0, 
соае [рс] .ор мо; 


вычисляет выражение по сгенерированному коду 
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збасКр = 0; 

рс = 0; 

мһі1е (сое [рс] .ор != МЈ) 
(*соде [рс++] .ор) (); 

геёцүп ѕіаск [0]; 


} 


В этом цикле выполняется программная эмуляция стековой машины, которая по 
сути делает то, что происходит в реальном компьютере на аппаратном уровне. 
Вот несколько характерных операций: 

/* ризпор: помещает число в стек; число - следующее слово в 


потоке кода */ 
уоіа риѕћор (уоіа) 


ѕсаск [5=©ёаскр++] = соде [рс++] .уа1ае; 


/* дӢіуор: вычисляет отношение двух выражений */ 
уоіа аіуор (уоіа) 


іп 1еЕб, клаве; 
үіҺС = збаск [--з6асКр]; 
1еЕЕ = ѕбаск [--ѕёаскр]; 
1Е (клаве == 0) 
ерх1пЕЕ ("аіуійе %а ру 2его\п", 1еЕЁ); 
ѕсаск [=©ёаскр++] = ІеЁі / клаве; 


} 


Обратите внимание, что проверка деления на нуль фигурирует в функции аіуор, 
а нев депегасе. 

Условное выполнение, ветвление и циклы выполняются путем модифицирова- 
ния счетчика инструкций. В результате управление передается в другое место мас- 
сива функций. Например, оператор собо всегда устанавливает значение переменной 
рс, а условный оператор — только если условие истинно. 

Естественно, что массив со@е является внутренним для интерпретатора. 
Но представим себе, что сгенерированную программу необходимо сохранить в фай- 
ле. Если выписать явные адреса функций, получится непереносимый и неустойчи- 
вый результат. Но вместо этого можно выписать константы, представляющие эти 
функции, — скажем, 1000 для адаор, 1001 для риѕћор и т.д., — а затем при считы- 
вании программы в память для выполнения преобразовать эти относительные кон- 
станты снова в указатели на функции. 

Если взглянуть на файл, генерируемый этой процедурой, он напомнит нам поток 
инструкций виртуальной машины, реализующих элементарные операции нашего 
мини-языка, а функция депегаее окажется компилятором языка в коды виртуаль- 
ной машины. Вообще, виртуальная машина — идея не новая, но недавно она снова 
вошла в моду благодаря языку Јауа и его виртуальной машине ]ауа Уігіџа] Масһіпе 
(УМ). С их помощью легко создавать хорошо переносимые, высокоэффективные 
представления программ, написанных на языке высокого уровня. 
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9.5. Программы, пишущие программы 


Возможно, наиболее примечательная черта функции депегаее состоит в том, 
что это программа, пишущая другую программу: ее выходные данные представляют 
собой поток выполняемых инструкций для другой (виртуальной) системы или ма- 
шины. Это именно то, что делают компиляторы, переводящие исходный код на язык 
машинных инструкций, так что идея, конечно, не нова. На самом деле программы, 
пишущие другие программы, попадаются то тут, то там в самых разных формах. 

Один из распространенных примеров — это динамическое генерирование 
НТМГ-кода для \!еБ-страниц. НТМІ. — это язык, хотя и ограниченный, причем в 
своем составе он может содержать код ЈауаЅсгірі. \еЬ-страницы часто генерируют- 
ся в реальном времени (на лету) программами, написанными на языках Рег] или С, 
и содержат специфическую информацию (например, результаты поиска или целена- 
правленную рекламу), определяемую поступающим на сервер запросом. В этой кни- 
ге мы пользовались специализированными языками для описания графиков, рисун- 
ков, таблиц, математических выражений и предметного указателя. Еще один при- 
мер — это РоѕіЅсгірё, язык программирования, текст на котором генерируется 
текстовыми редакторами, графическими и многими другими программами. На фи- 
нальном этапе допечатной подготовки вся эта книга была представлена в виде 
РоѕіЅсгірї-программы из 57 000 строк. 

Документ — это, конечно, статическая программа, но тем не менее идея использо- 
вания языка программирования как системы обозначений в специализированной 
области знаний остается исключительно плодотворной. Много лет назад программи- 
сты мечтали, чтобы компьютеры писали все программы за них самостоятельно. Воз- 
можно, эта мечта никогда не осуществится, однако современные компьютеры уже пи- 
шут довольно много программ за нас, причем часто для представления такой инфор- 
мации, которую мы раньше и не подумали бы описывать на языках программирования. 

Наиболее распространенная программа, пишущая другие программы, — это ком- 
пилятор, переводящий с языка высокого уровня на язык машинных инструкций. 
Но часто бывает полезно транслировать исходный код в код на другом языке, также 
высокого уровня. В предыдущем разделе упоминались генераторы синтаксических 
анализаторов, которые преобразуют определения грамматик языков в программы 
на С, выполняющие синтаксический разбор этих языков. Для этих целей часто 
используется язык С, который в этом случае служит чем-то вроде “языка ассемблера 
высокого уровня”. Моаша-3 и С++ как раз являются примерами языков общего на- 
значения, первые компиляторы которых создавали С-код, транслируемый затем 
стандартным компилятором С. Этот подход имеет ряд преимуществ — в том числе 
преимущества быстродействия (поскольку программы выполняются со скоростью 
С-программ) и переносимости (компиляторы можно перенести в любую среду, 
в которой имеется компилятор С). На раннем этапе существования упомянутых 
языков это очень помогло их всеобщему распространению. 

Еще один пример можно привести в связи с \!15иа] Ваѕіс. Его графический 
интерфейс генерирует набор операторов присваивания этого языка для инициали- 
зации объектов, которые пользователь выбирает из меню и позиционирует на экране 
с помощью мыши. Многие другие языки также имеют “визуальные” среды програм- 
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мирования и программы-“мастера”, которые синтезируют код пользовательских ин- 
терфейсов по нескольким щелчкам мышью. 

Несмотря на богатые возможности генераторов программ, так же как и на суще- 
ствование множества других удачных примеров, специальные системы обозначений 
ценятся не так высоко, как следовало бы, и отдельные программисты пользуются 
ими нечасто. А ведь всегда есть много возможностей создать некоторую часть кода с 
помощью программы, воспользовавшись преимуществами автоматизации. Далее 
приведено несколько примеров с генерированием кода на языках С и С++. 

Операционная система Р]ап 9 генерирует сообщения об ошибках на основании 
заголовочного файла, содержащего имена и комментарии. Комментарии автомати- 
чески конвертируются в литеральные строки в кавычках и объединяются в массив, 
индексируемый перечислимыми символическими константами. Вот структура заго- 
ловочного файла: 


/* еггогѕ.һ: стандартные сообщения об ошибках */ 


епит { 
Ереги, /* Отказано в допуске */ 
Еіо, /* Ошибка ввода-вывода */ 
ЕЁі1е, /* Файл не существует */ 
Етем, /* Исчерпан лимит памяти */ 


Езрасе, /* Не хватает места в файле */ 
Еагеа /* Виноват Гриша */ 


}; 


Получив на вход эти данные, несложная программа генерирует следующий набор 
деклараций для сообщений об ошибках: 


/* сгенерировано автоматически; не править. */ 
сһаг *еггз[] = { 
"Отказано в допуске", /* Ерегм */ 
"Ошибка ввода-вывода", /* Е1о */ 
"Файл не существует", /* ЕЁ11е */ 
"Исчерпан лимит памяти", /* Еме */ 
"Не хватает места в файле", /* Езрасе */ 
"Виноват Гриша", /* Едгед */ 


}; 


Этот подход имеет ряд преимуществ. Во-первых, связь между перечислимыми 
константами и строками, которые они представляют, самодокументирована и строго 
формальна. Информация фигурирует только в одном месте, и из этого одного места 
генерируется весь код, поэтому обновлять данные достаточно легко. Если бы ин- 
формация была разбросана, неизбежно возникала бы ее рассинхронизация. Наконец, 
легко устроить так, чтобы соответствующий С-файл генерировался и компилиро- 
вался заново всякий раз, когда в заголовочный файл вносятся изменения. Если не- 
обходимо изменить текст какого-либо сообщения об ошибке, достаточно модифици- 
ровать заголовочный файл и перекомпилировать систему. Все сообщения во всех 
местах обновятся автоматически. 
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Программу-генератор можно написать на любом языке. Это легко сделать, 
например, на языке обработки строк типа Рег]: 


# епит.р]1: генерирует сообщения об ошибках из епим и комментариев 
рк1пЕ "/* сгенерировано автоматически; не править. */\п\п"; 


ргіп "срак *екхз[] = {\п"; 
мһі1е (<>) { 
сһор; удаление конца строки 


1Е (/^\5%* (Е[а-20-9]+),?/) {. 
Ѕпате = $1; сохранение имени 
8/.*\/\* *//; удаление вплоть до /* 
5/ *\*\///; # удаление */ 
ргіпе "\6\"$_\", /* $паше */\п"; 


первое слово - Е. 


+ + ++ 


} 
реп "};\п"; 


Здесь снова работают регулярные выражения. Выбираются строки, первые поля 
которых являются идентификаторами с запятыми после них. При первой подста- 
новке удаляются все символы до первого непустого символа комментария, а при 
второй — закрывающая скобка комментария и пустые символы перед ней. 

В ходе тестирования одного из компиляторов Энди Кёниг (Апау Коеп!5) разра- 
ботал удобный способ оформления кода на С++ для проверки того, что компилятор 
действительно способен находить ошибки в программе. Фрагменты кода, которые 
должны были вызывать диагностические сообщения компилятора, сопровождались 
специальными комментариями с описаниями ожидаемых сообщений. Каждая такая 
строка начиналась с /// (чтобы отличаться от обычных комментариев) и регуляр- 
ного выражения, соответствовавшего диагностическим сообщениям к этой строке. 
Например, следующие фрагменты кода должны привести к выдаче диагностики: 

116 Е() {} 
/// магп1па.* поп-уоіа Ёцпсёіоп .* ѕһоџ1а гесигп а уа1ае 


уоіа 9() {гебагп 1;} 
/// еххохг.* уо1а Ғопсёіоп пау пої геёцгп а уа1ще 


Если пропустить второй фрагмент через компилятор С++, он выведет ожидаемое 
сообщение, соответствующее заданному регулярному выражению: 


= СС х.с 
"х.с", Ііпе 1: еггог (321): уоіа ЕапсЕе1оп тау пос гебагп а уа1ае 


Каждый такой фрагмент кода компилируется, а затем выходные данные компи- 
ляции сравниваются с ожидаемой диагностикой. Этот процесс выполняется ко- 
мандным сценарием с привлечением программ на АмК. Если тест заканчивается 
неудачей, значит, сообщения компилятора отличаются от ожидаемых. Поскольку 
комментарии представляют собой регулярные выражения, сравнение производится 
по нестрогим правилам — несколько произвольно. Их можно сделать более или 
менее строгими в зависимости от цели тестирования. 

Идея комментариев, имеющих определенное семантическое значение для 
программы, не нова. Они существуют в языке РоѕіЅсгірѓ, где обычные комментарии 
начинаются со знака %, а те, которые начинаются с двойного знака %%, могут нести 
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дополнительную информацию о номерах страниц, ограничительных рамках страни- 
цы, именах шрифтов и т.д.: 
%%РасдеВоџпаіпдВох: 126 307 492 768 
%%Ррадеѕ: 14 
%%ПоситепЕРопез: Не1уеёіса Тітеѕ-Іба1іс Т1тез-Ротмап 
Іисіааѕапѕ-Туремгіёег 


В языке Јауа комментарии, начинающиеся с /** и заканчивающиеся * /, исполь- 
зуются для создания документации на класс, определение которого следует за ком- 
ментарием. Обобщением самодокументированного кода является так называемое 
содержательное программирование (Шегайе ртоётатттЕ), при котором программа и 
ее документация интегрируются в одно целое, позволяющее с помощью одного про- 
цесса напечатать документацию для чтения, а с помощью другого — подготовить 
программу к компиляции и выполнению. 

Во всех приведенных примерах важно отметить роль систем обозначений, смеше- 
ния и совместного использования языков, активное привлечение утилит и оболочек. 
Все эти сочетания позволяют усилить эффект применения отдельных компонентов. 


Упражнение 9.15. Одна из старых курьезных задач программирования состоит в 
том, чтобы написать такую программу, которая бы при выполнении выводила в точ- 
ности сама себя в виде исходного кода. Это очень особый случай программы, пишу- 
щей программу. Попробуйте-ка сделать это на одном из ваших любимых языков. 


9.6. Генерирование кода с помощью макросов 


Если задача не чрезмерно велика и писать программу для генерирования про- 
граммы нецелесообразно, можно прибегнуть к помощи макросов, которые бы созда- 
вали часть кода на этапе компиляции. В этой книге мы неоднократно призывали не 
пользоваться макросами и условной компиляцией. Эти средства портят стиль про- 
граммирования и создают проблемы. Но все-таки у них есть свое место под солнцем 
и право на существование. В конце концов, иногда именно простая текстовая под- 
становка дает правильное решение задачи. В нашем примере мы воспользуемся мак- 
ропроцессором С/С++ для сборки одной искусственной программы, изобилующей 
повторениями. 

Например, программа для оценки быстродействия элементарных языковых 
конструкций (см. главу 7) использует препроцессор для сборки тестов в единое 
целое путем их заключения в код-оболочку. Суть теста состоит в том, чтобы инкап- 
сулировать фрагмент кода в цикл, в котором запускается таймер, фрагмент выпол- 
няется много раз, фиксируются показания таймера и выводится отчет о результатах. 
Весь повторяемый код включен в несколько макроопределений, а код, подвергаю- 
щийся измерениям, передается в них как аргумент. Основной макрос приобретает 
следующую форму: 

#деҒіпе ІООр (СОрЕ) { 
60 = с1осКк(); 
Бог (і = 0; 1 < п; і++) { СОрЕ; } 
ргіпё# ("%7а ", с1оск() - 0); 


а 
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Обратные косые черты позволяют распространить тело макроса на несколько 
строк. Этот макрос используется в “операторах”, обычно выглядящих следующим 
образом: 


ООР (#1 = #2) 
ООР (Ё1 = #2 + #3) 
ООР (Ё1 = #2 - #3) 


Имеется еще несколько операторов инициализации, однако основная измери- 
тельная часть представлена этими макровызовами с одним аргументом, которые 
раскрываются в довольно большой объем кода. 

Макропроцессор можно использовать и для генерирования профессионального, 
коммерчески значимого кода. Барт Локанти (Вагї І.осапіћі) однажды написал высо- 
коэффективную версию двумерной графической операции. Эта операция, называю- 
щаяся рібЬ1Є или гаѕбегор, трудно поддается оптимизации быстродействия, по- 
тому что в ней много аргументов комбинируется сложным способом. Однако после 
тщательного анализа вариантов Локанти развел эти комбинации по разным циклам, 
которые можно было оптимизировать независимо. Каждый случай затем кодировал- 
ся с применением макроподстановки, аналогичной примеру с тестированием быст- 
родействия; все варианты были учтены в одном большом операторе ѕмієсћһ. Перво- 
начальный исходный код имел длину несколько сотен строк, а после развертывания 
макросов приобретал длину в несколько тысяч. Развернутый таким образом код не 
был оптимальным, однако, учитывая сложность задачи, вполне практичным и про- 
стым в разработке. К тому же для высокоэффективного кода он был достаточно 
хорошо переносимым. 


Упражнение 9.16. В упражнении 7.7 требуется написать программу для измере- 
ния затрат на различные операции в С++. Воспользуйтесь идеями этой главы и 
напишите другую версию этой программы. 


Упражнение 9.17. В упражнении 7.8 требуется разработать модель стоимости 
для языка Јауа, в котором макроопределения не предусмотрены. Решите эту про- 
блему, написав другую программу на каком-нибудь другом языке (или языках) 
по своему выбору, которая бы сама генерировала Јауа-версию и автоматизировала 
измерение времени. 


9.7. Компиляция в реальном времени 


В предыдущем разделе мы рассматривали программы, которые пишут програм- 
мы. В каждом из примеров сгенерированная программа возникала в виде исходного 
кода, и ее еще нужно было компилировать или интерпретировать для последующего 
выполнения. Однако можно генерировать и код, сразу же готовый к выполнению. 
Для этого генерируется не исходный код, а поток машинных инструкций. Этот про- 
цесс известен под названием компиляции “в реальном времени” (оп-ће-Йу) или 
“по требованию” (јиѕі-іп-іпе). С учетом удобного и звучного сокращения ЈІТ, вто- 
рой термин несколько популярнее. 
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Скомпилированный код неизбежно непереносим — он работает только на одном 
типе процессоров, хотя и очень быстро. Рассмотрим следующее выражение: 


пах (Ы, с/2) 


Необходимо получить значение с, разделить на два, сравнить результат ср и вы- 
брать большее. Если вычислять выражение на той виртуальной машине, которую мы 
обрисовали в общих чертах ранее, можно было бы устранить проверку деления на 
нуль в діуор. Поскольку 2 никогда не равно 0, эта проверка все равно бесполезна. 
Однако при любом варианте реализации виртуальной машины, который мы намети- 
ли, устранить эту проверку никак не получится. При выполнении операции деления 
делитель неизменно сравнивается с нулем, как бы эта операция ни была реализова- 
на. Вот где может помочь динамическое генерирование кода. Если построить код для 
выражения непосредственно, а не просто собрать в кучу заранее определенные опе- 
рации, можно избежать проверки делителя, который и так гарантированно не равен 
нулю. На самом деле можно зайти даже дальше. Если все выражение постоянно, как, 
например, тах (3*3, 4/2), можно вычислить его один раз при генерировании кода 
и заменить константой 9. Если это выражение фигурирует в цикле, то при каждом 
его проходе будет экономиться некоторое время. Если цикл выполняется достаточно 
много раз, то экономия от его оптимизации оправдает время, затраченное на анализ 
выражения и генерирование оптимального кода для него. 

Ключевая идея состоит в том, что система обозначений дает нам общий способ 
описания задачи, однако компилятор для этой системы может еще и приспосабли- 
вать код к специфическим деталям вычислений. Например, в виртуальной машине 
для регулярных выражений полезно было бы иметь операцию для сравнения лите- 
ральных символов: 


іпё таєсһсһаг (іп 1іёега1, сһаг *ёехі) 


гецгп *ёехі == 1ібега1; 


} 


Однако если мы генерируем код для конкретного заданного текста, то значение 
того или иного литерала уже фиксировано — например, 'х' — и вместо этого можно 
использовать такую операцию: 


іп паєсһх (сһаг *бехё) 


{ 


геёцгп *ёехі == 'х'; 


Вместо того чтобы заранее определять специальную операцию для каждого лите- 
рального символьного значения, можно упростить дело и генерировать код опера- 
тивно только для тех операций, которые нам действительно нужны для обработки 
текущего выражения. Обобщая идею на полный набор операций, можно написать 
компилятор реального времени для трансляции регулярных выражений в специаль- 
ный код, оптимизированный для этих конкретных выражений. 

Именно это сделал Кен Томпсон (Кеп Тһотрѕоп) при реализации регулярных 
выражений на машине ІВМ 7094 в 1967 г. Его версия генерировала небольшие блоки 
двоичных инструкций ІВМ 7094 для различных операций выражения, затем 
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“сшивала” их вместе и запускала получившуюся программу путем ее вызова как 
обычной функции. Аналогичные методы можно применять для создания специфи- 
ческих потоков инструкций, обновляющих экран в графических системах, где суще- 
ствует так много особых случаев и исключений, что эффективнее генерировать ди- 
намический код для каждого из них на ходу, чем выписать их все заранее или вклю- 
чить условное ветвление в код более общего характера. 

Демонстрация реального компилятора “по требованию” увела бы нас в дебри 
конкретного набора машинных инструкций, но тем не менее посмотреть хотя бы в 
общих чертах, как работают подобные системы, очень полезно. Остальная часть это- 
го раздела посвящена скорее общим идеям и рассуждениям, чем деталям конкрет- 
ных реализаций. 

Вспомним, что мы оставили нашу виртуальную машину в следующем виде: 

Соде соае [МСОПЕ] ; 
іпё збасКк [МЅТАСК]; 


іпё ѕёбаскр; 
116 рс; /* счетчик инструкций */ 


Тгее *(; 
Е = рагѕе (); 


рс = депегаее(0, +); 
соае [рс] .ор = М; 


зсасКкр = 0; 
рс = 0; 
мһі1е (соае[рс].ор != М) 


(*соде [рс++] .ор) (); 
геіигп ѕбаск [0]; 


Чтобы приспособить этот код к компиляции в реальном времени, необходимо 
внести некоторые изменения. Во-первых, массив содае должен стать массивом 
не указателей на функции, а выполняемых инструкций. Будут ли инструкции иметь 
тип сһах, іп? или 1опа, зависит от конкретного процессора, для которого выпол- 
няется компиляция. Пока предположим тип іпё. После генерирования кода он 
будет вызываться как функция. Виртуального счетчика инструкций здесь быть не 
должно, поскольку код будет последовательно перебираться в собственном цикле 
процессора. После окончания вычислений произойдет возврат управления, как из 
обычной функции. 

Также мы можем выбрать между ведением отдельного стека операндов для на- 
шей машины и использованием собственного стека процессора. Каждый из подходов 
имеет свои преимущества, но мы решили обойтись отдельным стеком и сосредото- 
читься на подробностях самого кода. В этом случае реализация машины приобретает 
следующий вид: 

суреаеЕ 1пе Соае; 
Соде соае [МСОПЕ] ; 
іп соаер; 


іпё ѕбаск [МЅТАСК]; 
106 ѕбаскр; 


Тгее *(; 
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уоіа (*Ёп) (уоіа); 

116 рс; 

Е = рагѕе(); 

рс = депегаее(0, +); 

депгеіцгп (рс); /* генерирование кода для возвращения */ 


ѕёаскр = 0; 

Ғ1џѕһсасһеѕ (); /* синхронизация памяти с процессором */ 

Еп = (уоіа(*) (уоіа)) соае; /* приведение массива к указателю */ 
(*Еп) (); /* вызов функции */ 


гесцгп зіаск [0]; 


После завершения функции ҷепегабе функция депгеЕдкп создает последова- 
тельность инструкций для возвращения управления из сгенерированного кода в 
функцию еуа1. 

Функция #1чѕһсасһезѕ реализует операции по подготовке процессора к выпол- 
нению сгенерированного кода. Современные компьютеры и системы работают быст- 
ро в частности потому, что хранят инструкции и данные в кэш-памяти и используют 
внутренние конвейерные каналы, позволяющие параллельно выполнять несколько 
последовательных инструкций. Кэш-память и конвейеры воспринимают поток ин- 
струкций как статический; если же код сгенерирован непосредственно перед выпол- 
нением, процессор может запутаться. Процессору необходимо сбросить все из кон- 
вейерного канала и очистить кэш-память, а уже потом выполнять новые инструкции. 
Все эти операции целиком и полностью аппаратно-зависимы. Реализации функции 
Е1азнсаснез на разных компьютерах будут совершенно различны. 

Примечательное выражение (уоіа (*) (уо1а) ) сое служит для преобразова- 
ния адреса массива, который содержит сгенерированные инструкции, в указатель на 
функцию, который можно использовать для вызова этого кода как функции. 

Генерирование кода не составляет особых технических трудностей, хотя для того, 
чтобы делать это эффективно, придется потрудиться. Начнем с некоторых 
“кирпичиков”. Как и раньше, в процессе компиляции запоминаются массив соае и 
его индекс. Для простоты мы сделали их глобальными, как и раньше. Теперь можно 
написать функцию для помещения инструкций в код: 


/* ет1е: добавление инструкции в поток кода */ 
уоіа ет1* (Соае іпѕіё) 


соде [сойер++] = 118%; 


Сами инструкции могут определяться в виде процессорно-зависимых макросов 
или мини-функций, которые “собирают” инструкции путем заполнения полей слова 
инструкции. Гипотетически можно было бы написать функцию роргеч для генери- 
рования кода по извлечению числа из стека и помещению его в регистр процессора 
и еще одну, разнгеч, для генерирования кода по извлечению числа из регистра и 
помещения в стек. Наша новая функция адор пользовалась бы ими следующим 
образом, при наличии предопределенных констант, описывающих инструкции 
(типа АООТМ$Т) и их положение (различные сдвиги ЗНТЕТ, определяющие формат): 


/* аййор: генерирует инструкцию Арр */ 
уоіа аааор (уоіа) 


{ 
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Соае іпѕё; 


роргед (2); /* извлечь из стека в регистр 2 */ 

роргед (1); /* извлечь из стека в регистр 1 */ 

1056 = АШОТМУТ << ІМЅТЅНІЕРТ; 

1056 |= (81) << ОРТЗНТЕТ; 

1056 |= (В2) << ОРЗ5НТЕТ; 

еті (1156); /* выдать Арр В1, В2 в поток */ 

рчѕһгед (2); /* поместить значение регистра 2 в стек */ 


} 


Все это лишь начало. Если бы пришлось действительно писать компилятор ре- 
ального времени, необходимо было бы прибегнуть к оптимизации. Для добавления 
константы не нужно помещать ее в стек, извлекать оттуда, а затем уже добавлять; 
достаточно добавить ее непосредственно. Аналогичные соображения позволяют оп- 
тимизировать почти все нерациональные операции. Но даже в этом виде функция 
адӣор уже работает значительно быстрее, чем более ранние версии, потому что раз- 
ные операции не сшиваются вместе посредством вызовов отдельных функций. Вме- 
сто этого код для их выполнения помещается в память в виде единого блока инст- 
рукций, а их перебор выполняется реальным счетчиком процессора. 

Функция депегабе выглядит практически так же, как и в реализации виртуаль- 
ной машины. Однако в этот раз она генерирует реальные инструкции этой машины, 
а не указатели на заранее определенные функции. Чтобы генерировать высокоэф- 
фективный код, эта функция должна приложить некоторые усилия для поиска под- 
ставляемых констант и выполнения других аналогичных оптимизаций. 

Итак, мы вкратце рассмотрим вопросы генерирования кода, в общих чертах наме- 
тив некоторые методы работы реальных компиляторов и полностью проигнорировав 
многие другие. Также в нашем изложении пропущены многие проблемы, вызванные 
сложным устройством современных процессоров. И все же мы продемонстрировали на 
примерах, что программа может анализировать описание задачи и продуцировать спе- 
циализированный код для ее эффективного решения. Этими идеями можно восполь- 
зоваться для самостоятельной разработки сверхбыстрой версии агер, реализации 
мини-языка для своих собственных целей, разработки и реализации виртуальной 
машины, оптимизированной для специальных вычислений, или даже, с некоторой 
помощью, написания компилятора для нового интересного языка. 

Регулярное выражение имеет мало внешнего сходства с программой на языке 
С++, однако и то и другое — системы обозначений для решения определенных задач. 
Имея правильную систему обозначений, можно облегчить трудности решения мно- 
гих проблем. Разработка и реализация системы обозначений — это необычное и 
увлекательное занятие. 


Упражнение 9.18. Компилятор реального времени сгенерирует более быстрый 
код, если он сможет заменить выражения типа тах (3*3, 4 /2), содержащие только 
константы, их явными значениями. Как компилятор должен вычислять значение 
такого выражения после того, как оно опознано им? 


Упражнение 9.19. Как бы вы протестировали компилятор реального времени? 


Раздел 9.7 Компиляция в реальном времени 281 


Дополнительная литература 


Подробное обсуждение вопросов программирования с применением утилит и 
командных оболочек, которое столь развито в среде Ошх, содержится в книге Вгіап 
Кегпіећап, Ко Рще, Тле тх Ргорғгаттіпр Епоігоптепі (Ртепіісе Най, 1984). Глава 8 
этой книги представляет полную реализацию несложного языка программирова- 
ния — от грамматики в формате уасс до исполняемого кода. 

В книге Роп Кпиёћ, ТЕХ: Тйе Ргортат (Айаіѕоп-Меѕ]еу, 1986) описывается слож- 
ная программа форматирования документов; вся программа (около 13 000 строк на 
языке Разса|) представлена в стиле “содержательного программирования”, в кото- 
ром текст программы содержит подробные пояснения и служит сам себе документа- 
цией, потому что именно из него документация извлекается специальными про- 
граммами. В книге Сһгіѕ Егазег, Оауіа Напзоп, А Аеатвеа Ме С Сотриег: Реѕірп апа 
Ітріетепіайоп (АЧЧ1зоп-\ез]еу, 1995) предлагается такого же рода описание одного 
из компиляторов АМ$] С. 

Виртуальная машина ]ауа описана в книге Тіт ГлпаБо]т, Егапк УеШт, Тйе Јаоа 
Ипиа! Масйте Ѕресійсайоп, 214 Едійоп (А4аіѕоп-Ұеѕ]еу, 1999). 

Алгоритм Кена Томпсона (Кеп Тһотрѕоп), один из первых запатентованных 
программных продуктов, представлен в статье “Кевшаг Ехргеѕѕіоп Ѕеагсћ А]вог т”, 
Соттипісайопѕ оў ће АСМ, 1968, 11, 6, р. 419-422. Очень подробное изложение это- 
го предмета можно найти в книге ]еНгеу Е. Е. Еме], Маѕѓетпе Кевщат Ехргеѕѕіопѕ 
(О’ВеШу, 1997). 

Компилятор в реальном масштабе времени для операций двумерной графики 
описан в статье Кор Р\е, Вагї Госапёћі, Јоһћп Веіѕег, “Наг4\аге/бой\аге ТгайеоЁѕ Юг 
Вістар Старһісѕ оп {фе ВІЇ”, бойшаге—Ргасисе апа Ехрепепсе, ЕеЪгиагу 1985, 15, 2, 
р. 131-152. 


Эпилог 


Если бы только люди могли учиться на примерах из истории, какие уроки 
мы могли бы получить! Но, увы, нас ослепляют страсти и пристрастия, 
а свет жизненного опыта подобен фонарю на корме судна, который освеща- 
‘ет лишь волны позади нас! 


Сэмюэл Тейлор Кольридж. “Воспоминания” 
(батие! Тауют Соіепаве, КесоПесііопѕ) 


Мир программирования и вычислительной техники постоянно изменяется, и ин- 
тенсивность этих изменений все нарастает. Программистам приходится осваиваться 
с новыми языками, новыми утилитами, новыми системами и средами, а также с не- 
совместимыми изменениями предыдущих версий. Программы разрастаются, интер- 
фейсы усложняются, сроки сдачи работ сокращаются. 

И все же существует нечто постоянное, некие скалы в бурном море — очаги ста- 
бильности, благодаря которым уроки прошлого можно применить в будущем. 
Эта книга во многом основана именно на этих вечных ценностях. 


Простота и ясность — это первые и наиболее важные принципы, поскольку почти 
все остальные следуют из них. Реализуйте самый простой метод из тех, которые ра- 
ботают. Выбирайте самый простой алгоритм из всех достаточно быстрых для данной 
задачи и самую простую структуру данных, пригодную для решения. Соберите их в 
единое целое в простом и понятном коде. Не усложняйте без причины, если требо- 
вания быстродействия не вынуждают вас к этому. Интерфейсы должны быть лако- 
ничными и экономными — по крайней мере, до тех пор, пока не станет совершенно 
очевидно, что получаемые преимущества окупают их повышенную сложность. 


Общность часто идет рука об руку с простотой, поскольку позволяет решить 
задачу раз и навсегда, а не решать ее снова и снова для частных случаев. Часто это 
правильный подход и к переносимости: найти единственное общее решение, рабо- 
тающее во всех системах, вместо того, чтобы только подчеркивать и усиливать раз- 
личия между операционными средами. 


Эволюционность развития — это следующий принцип. Невозможно создать иде- 
альную программу с первого же раза. Интуиция, необходимая для нахождения пра- 
вильного решения, приходит только с опытом глубоких размышлений над задачами 
И проблемами. Хорошую систему не удастся построить ни на одном кавалерийском 
натиске, ни на одной усидчивости. Нужно считаться с реакцией пользователей; наи- 
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более эффективным следует считать цикл, состоящий из разработки, эксперименти- 
рования, обратной связи от пользователя и дальнейшей доработки. Программы, ко- 
торые мы пишем для себя, часто не получают никакого развития, а программы, по- 
купаемые у других, нередко изменяются слишком быстро, но не обязательно в луч- 
шую сторону. 

Интерфейсы составляют значительную часть стратегии программирования; во- 
просы взаимодействия компонентов вычислительного процесса возникают во мно- 
гих случаях. Самый распространенный случай — библиотеки, однако существуют 
еще интерфейсы между программами, а также между пользователями и программа- 
ми. Принципы простоты и общности играют особенно важную роль именно в проек- 
тировании интерфейсов. Делайте их согласованными, простыми в изучении и ис- 
пользовании, а затем придерживайтесь их как можно строже. Эффективной техни- 
кой является абстрагирование: вообразите себе идеально работающий компонент, 
библиотеку или программу; затем подгоните интерфейс под этот идеал, насколько 
возможно; скройте подробности реализации за четкой непроницаемой границей. 


Автоматизация — это принцип, который обычно несколько недооценивается. 
Часто бывает удобнее заставить компьютер сделать работу за вас, чем делать ее от 
руки. Мы видели примеры этого подхода в тестировании, в отладке, в анализе быст- 
родействия, а также в немалой степени при написании кода, где при правильной 
формулировке задачи программы могут сами писать такие программы, которые бы- 
ло бы трудно написать людям. 


Выбор системы обозначений также недооценивается, причем не только как спо- 
соб сообщить компьютеру, что он должен делать. Правильная система обозначений 
создает организованную среду для реализации широкого круга удобных программ- 
ных средств, а также создает костяк структуры для программ, которые пишут другие 
программы. Все мы хорошо владеем языками общего назначения, служащими для 
решения основной массы задач. Однако если задача столь специализирована и хо- 
рошо отработана, что ее программирование является почти механическим процес- 
сом, возможно, пора создать для нее систему обозначений, которая бы выражала ее 
естественным образом, а затем реализовать язык программирования для этой систе- 
мы. Одним из наших любимых примеров являются регулярные выражения, однако 
есть и другие бессчетные возможности для создания специализированных мини- 
языков. Они совсем не должны быть сложными, чтобы давать отличные практиче- 
ские результаты. 

Отдельные программисты нередко чувствуют себя маленькими винтиками 
вбольшой машине, поскольку им приходится использовать принудительно навя- 
занные языки и системы, а также решать задачи, поставленные кем-то другим. 
Однако в дальней перспективе все же имеет значение лишь то, как хорошо мы вы- 
полняем свой долг. Применяя некоторые идеи, предложенные в этой книге, вы вско- 
ре обнаружите, что с вашим кодом стало легче работать, отладка отнимает меньше 
времени и нервов, а стиль программирования стал более уверенным. Надеемся, что 
эта книга дала вам нечто для того, чтобы ваши усилия по программированию раз- 
личных задач давали больше плодов и приносили больше удовлетворения. 
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Женщина: Здесь ли моя тетушка Минни? 


Дрифтвуд: Что ж, можете войти и поискать, если хотите; если даже ее 
здесь нет, всегда можно найти взамен кого-нибудь получше. 
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